Hi all,
About 2 month ago, we had a discussion on this list about the fact
that CURLOPT_SSL_VERIFYHOST was most of the time used with a Boolean
value (true) instead of int values (0,1 or 2). This bad usage was
leading to some security issues. The result of this discussion was to
trigger a notice if someone tried to set the CURLOPT_SSL_VERIFYHOST to
true (boolean), and was committed to >= 5.4
On November 20th, Daniel (the author of libcurl) released cURL 7.28.1
which no longer support the 1 value for CURLOPT_SSL_VERIFYHOST. This
change introduced some bugs as #63795 (you'll find the cause of the
bug in the comments).
To fix this bug, and to minimize as much as possible the impact of
this change, I'm proposing to do the following changes in the libcurl
extension for future releases :
When using libcurl < 7.28.1, if someone try to set
CURLOPT_SSL_VERIFYHOST to 1 (or true), set the value to 1, but trigger
a notice to inform that this value is deprecated.
When using libcurl >= 7.28.1 if someone try to set
CURLOPT_SSL_VERIFYHOST to 1 (or true), set CURLOPT_SSL_VERIFYHOST to
2, trigger a notice to inform the user that this value is no longer
supported as of libcurl 7.28.1 but keep returning true.
Also, as stated by Remy in bug #63795, when PHP is built with
curl-wrappers, the context option "curl_verify_ssl_host" sets
CURLOPT_SSL_VERIFYHOST to 1. I would like to modify this code to set
CURLOPT_SSL_VERIFYHOST to 2. Since curl-wrappers is still marked as
experimental I don't think this will cause a lot of troubles.
If you have any comment, please do, otherwise, I'll commit those
changes on Friday to all branches (including 5.3).
Thanks
Pierrick
On Wed, Dec 19, 2012 at 5:35 AM, Pierrick Charron pierrick@webstart.frwrote:
Hi all,
About 2 month ago, we had a discussion on this list about the fact
thatCURLOPT_SSL_VERIFYHOSTwas most of the time used with a Boolean
value (true) instead of int values (0,1 or 2). This bad usage was
leading to some security issues. The result of this discussion was to
trigger a notice if someone tried to set theCURLOPT_SSL_VERIFYHOSTto
true (boolean), and was committed to >= 5.4On November 20th, Daniel (the author of libcurl) released cURL 7.28.1
which no longer support the 1 value for CURLOPT_SSL_VERIFYHOST. This
change introduced some bugs as #63795 (you'll find the cause of the
bug in the comments).To fix this bug, and to minimize as much as possible the impact of
this change, I'm proposing to do the following changes in the libcurl
extension for future releases :When using libcurl < 7.28.1, if someone try to set
CURLOPT_SSL_VERIFYHOSTto 1 (or true), set the value to 1, but trigger
a notice to inform that this value is deprecated.
I dont know if it is the good way to deal with that. Does the PHP user have
to be aware that
the underlying libcurl is gonna change ? The deprecated message may let
him think that in the next PHP version, the value will have disapeared,
but in fact,
its in the next libcurl version, regardless PHP version.
When using libcurl >= 7.28.1 if someone try to set
CURLOPT_SSL_VERIFYHOSTto 1 (or true), setCURLOPT_SSL_VERIFYHOSTto
2, trigger a notice to inform the user that this value is no longer
supported as of libcurl 7.28.1 but keep returning true.
Ok
Also, as stated by Remy in bug #63795, when PHP is built with
curl-wrappers, the context option "curl_verify_ssl_host" sets
CURLOPT_SSL_VERIFYHOSTto 1. I would like to modify this code to set
CURLOPT_SSL_VERIFYHOSTto 2. Since curl-wrappers is still marked as
experimental I don't think this will cause a lot of troubles.If you have any comment, please do, otherwise, I'll commit those
changes on Friday to all branches (including 5.3).
Julien.P
Hi Julien,
I think we need to trigger a notice to prevent users to write code
that may not work in future version even if it doesn't depend on our
changes but on libraries changes.
Maybe we could be more explicit and tell the user that the 1 value
will not be available as of libcurl 7.28.1 (I just hope that people
will not be confused on what is libcurl and what's the version of it).
Pierrick
On Wed, Dec 19, 2012 at 5:35 AM, Pierrick Charron pierrick@webstart.fr
wrote:Hi all,
About 2 month ago, we had a discussion on this list about the fact
thatCURLOPT_SSL_VERIFYHOSTwas most of the time used with a Boolean
value (true) instead of int values (0,1 or 2). This bad usage was
leading to some security issues. The result of this discussion was to
trigger a notice if someone tried to set theCURLOPT_SSL_VERIFYHOSTto
true (boolean), and was committed to >= 5.4On November 20th, Daniel (the author of libcurl) released cURL 7.28.1
which no longer support the 1 value for CURLOPT_SSL_VERIFYHOST. This
change introduced some bugs as #63795 (you'll find the cause of the
bug in the comments).To fix this bug, and to minimize as much as possible the impact of
this change, I'm proposing to do the following changes in the libcurl
extension for future releases :When using libcurl < 7.28.1, if someone try to set
CURLOPT_SSL_VERIFYHOSTto 1 (or true), set the value to 1, but trigger
a notice to inform that this value is deprecated.I dont know if it is the good way to deal with that. Does the PHP user have
to be aware that
the underlying libcurl is gonna change ? The deprecated message may let
him think that in the next PHP version, the value will have disapeared,
but in fact,
its in the next libcurl version, regardless PHP version.When using libcurl >= 7.28.1 if someone try to set
CURLOPT_SSL_VERIFYHOSTto 1 (or true), setCURLOPT_SSL_VERIFYHOSTto
2, trigger a notice to inform the user that this value is no longer
supported as of libcurl 7.28.1 but keep returning true.Ok
Also, as stated by Remy in bug #63795, when PHP is built with
curl-wrappers, the context option "curl_verify_ssl_host" sets
CURLOPT_SSL_VERIFYHOSTto 1. I would like to modify this code to set
CURLOPT_SSL_VERIFYHOSTto 2. Since curl-wrappers is still marked as
experimental I don't think this will cause a lot of troubles.If you have any comment, please do, otherwise, I'll commit those
changes on Friday to all branches (including 5.3).Julien.P
On Thu, Dec 20, 2012 at 4:57 PM, Pierrick Charron pierrick@webstart.frwrote:
Hi Julien,
I think we need to trigger a notice to prevent users to write code
that may not work in future version even if it doesn't depend on our
changes but on libraries changes.Maybe we could be more explicit and tell the user that the 1 value
will not be available as of libcurl 7.28.1 (I just hope that people
will not be confused on what is libcurl and what's the version of it).
Well, I'd say what have we done before about that ?
We have already met lib API changes (libcurl, libxml, other usefull libs
exposed to the user), let's see what we did :-)
Julien.P
I don't remember of any change in other binding (not saying there were
not any) which like this one were removing a feature without giving an
alternative to do the same thing. If someone can point me to one, I'll
be glad to look at how we managed this.
Pierrick
On Thu, Dec 20, 2012 at 4:57 PM, Pierrick Charron pierrick@webstart.fr
wrote:Hi Julien,
I think we need to trigger a notice to prevent users to write code
that may not work in future version even if it doesn't depend on our
changes but on libraries changes.Maybe we could be more explicit and tell the user that the 1 value
will not be available as of libcurl 7.28.1 (I just hope that people
will not be confused on what is libcurl and what's the version of it).Well, I'd say what have we done before about that ?
We have already met lib API changes (libcurl, libxml, other usefull libs
exposed to the user), let's see what we did :-)Julien.P
The following solution was implemented :
https://github.com/php/php-src/commit/517f800277a11d6ce05b0e1afcd0e76dc544d452
Pierrick
Hi all,
About 2 month ago, we had a discussion on this list about the fact
thatCURLOPT_SSL_VERIFYHOSTwas most of the time used with a Boolean
value (true) instead of int values (0,1 or 2). This bad usage was
leading to some security issues. The result of this discussion was to
trigger a notice if someone tried to set theCURLOPT_SSL_VERIFYHOSTto
true (boolean), and was committed to >= 5.4On November 20th, Daniel (the author of libcurl) released cURL 7.28.1
which no longer support the 1 value for CURLOPT_SSL_VERIFYHOST. This
change introduced some bugs as #63795 (you'll find the cause of the
bug in the comments).To fix this bug, and to minimize as much as possible the impact of
this change, I'm proposing to do the following changes in the libcurl
extension for future releases :When using libcurl < 7.28.1, if someone try to set
CURLOPT_SSL_VERIFYHOSTto 1 (or true), set the value to 1, but trigger
a notice to inform that this value is deprecated.When using libcurl >= 7.28.1 if someone try to set
CURLOPT_SSL_VERIFYHOSTto 1 (or true), setCURLOPT_SSL_VERIFYHOSTto
2, trigger a notice to inform the user that this value is no longer
supported as of libcurl 7.28.1 but keep returning true.Also, as stated by Remy in bug #63795, when PHP is built with
curl-wrappers, the context option "curl_verify_ssl_host" sets
CURLOPT_SSL_VERIFYHOSTto 1. I would like to modify this code to set
CURLOPT_SSL_VERIFYHOSTto 2. Since curl-wrappers is still marked as
experimental I don't think this will cause a lot of troubles.If you have any comment, please do, otherwise, I'll commit those
changes on Friday to all branches (including 5.3).Thanks
Pierrick