Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63620
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.170 as permitted sender)
MIME-Version: 1.0
Sender: sebastian.krebs.berlin@gmail.com
In-Reply-To: <k6b356$jl6$2@ger.gmane.org>
References: <CAB75mSX-cMqZPTfv2vc8fakD_pr31qPR+kO5_O=zYiVoy4xH2w@mail.gmail.com>
	<CAL+t6cF=e_55=v9bZVy7Tv=V3M4CUQLueu=b5Efa+MD0ewG_qA@mail.gmail.com>
	<k6b356$jl6$2@ger.gmane.org>
Date: Thu, 25 Oct 2012 12:38:34 +0200
Message-ID: <CALtuQzB2TFJ_hGTT4YuHDRo6_2it=pJTi1hVd+cvMkEX14RpfA@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=047d7b62275e1a690a04ccdfcec1
Subject: Re: [PHP-DEV] Changing the default value of "true" for CURLOPT_SSL_VERIFYHOST
From: krebs.seb@gmail.com (Sebastian Krebs)

--047d7b62275e1a690a04ccdfcec1
Content-Type: text/plain; charset=ISO-8859-1

2012/10/25 crankypuss <fullmoon@newsguy.com>

> On 10/24/2012 11:34 PM, Sherif Ramadan wrote:
>
>> On Thu, Oct 25, 2012 at 1:03 AM, JJ <jawed@php.net> wrote:
>>
>>> Hey all - I'd like start a discussion around pull request 221
>>> (https://github.com/php/php-**src/pull/221<https://github.com/php/php-src/pull/221>
>>> ).
>>>
>>> In short, there's a high volume of [incorrect] code out there which
>>> looks like:
>>>
>>> curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, true);
>>>
>>> Instead of what, in all likelyhood, the code meant to do:
>>>
>>> curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
>>>
>>> This is due to the convert_to_long_ex call which converts "true" to
>>> 1L. CURLOPT_SSL_VERIFYHOST being set to 1L bypasses common name
>>> validation within libcurl.
>>>
>>> My solution was to check the type for CURLOPT_SSL_VERIFYHOST: if it is
>>> boolean and true, the opt value for libcurl is set to 2L.
>>>
>>> I understand that engineers should have the proper option value to
>>> begin with but weighing the impact of this (MITM attacks) against
>>> doing what they probably meant anyways is worth the presumption.
>>>
>>> Please discuss and adjust the patch if necessary.
>>>
>>> - JJ
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>> While I think it's a good idea to set the value of the option to 2, as
>> is recommended for production in the documentation, I think the idea
>> of implicitly converting a bool(true) to 2L internally might lead to
>> unexpected behavior since some people might actually depend on normal
>> PHP behavior to cast a bool(true) to 1 (and that might be what they
>> actually intended).
>>
>> I understand there are people out there that don't read the
>> documentation and aren't aware of the difference between
>> curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2); and curl_setopt($ch,
>> CURLOPT_SSL_VERIFYHOST, true); but still... I don't think this is a
>> good idea either.
>>
>> We should probably just elaborate on this point a bit more in the
>> documentation. Perhaps add a note and an example to illustrate. I
>> notice that people tend to pay more attention to examples than
>> anything else in the docs.
>>
>>
> Booleans ought to be 1 and 0.  Casting a boolean to 2 is just wrong, a way
> to fix badly written code a few people have written and in so doing risk
> the breakage of far more code that is correct.


Thats not completely true. Boolean 'false' is equal to 0 and Boolean 'true'
is something different than 0, that _may_ be 1 (and in most cases is), but
it's not limited too. Just said.


>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
github.com/KingCrunch

--047d7b62275e1a690a04ccdfcec1--