Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63624
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain webstart.fr from 209.85.219.42 cause and error)
MIME-Version: 1.0
In-Reply-To: <CADajX4ALHEzXDQQuqwjiOx5bdgUVG+4pXGAJ_Unano3z9S5ZSQ@mail.gmail.com>
References: <CAB75mSX-cMqZPTfv2vc8fakD_pr31qPR+kO5_O=zYiVoy4xH2w@mail.gmail.com>
	<CAL+t6cF=e_55=v9bZVy7Tv=V3M4CUQLueu=b5Efa+MD0ewG_qA@mail.gmail.com>
	<CAB75mSVg10VURjFmOhNQk87CqVP9FOQmcSzzgfMUTEb6S7WvxQ@mail.gmail.com>
	<CADajX4ALHEzXDQQuqwjiOx5bdgUVG+4pXGAJ_Unano3z9S5ZSQ@mail.gmail.com>
Date: Thu, 25 Oct 2012 09:28:07 -0400
Message-ID: <CAOfKkdRuhtMFzETieYsitGMprt+opVHnu+L4rQ5vYnfnS4an=A@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Cc: JJ <jawed@php.net>, Sherif Ramadan <theanomaly.is@gmail.com>, internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Changing the default value of "true" for CURLOPT_SSL_VERIFYHOST
From: pierrick@webstart.fr (Pierrick Charron)

I completely agree with Adam and others, we should not change the
behaviour to add any magic.

The ext/curl api was made to stay as close as possible from the
original libcurl api and it should stay the same (even if it's not
always implicit). A lot of people are often referring to the libcurl C
documentation to get more informations. Since it's supposed to be
almost a 1 to 1 binding everything (even bad use of
CURLOPT_SSL_VERIFYHOST with boolean) should work as expected without
any magic.

Pierrick

On 25 October 2012 02:19, Adam Harvey <aharvey@php.net> wrote:
>
> On 25 October 2012 13:46, JJ <jawed@php.net> wrote:
> > On Wed, Oct 24, 2012 at 10:34 PM, Sherif Ramadan
> > <theanomaly.is@gmail.com> wrote:
> >> 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.
> >
> > I highly doubt code that sets CURLOPT_SSL_VERIFYHOST =3D> true meant to
> > imply CURLOPT_SSL_VERIFYHOST =3D> 1...which essentially bypasses host
> > verification.
>
> They may have, even in spite of it being a bad idea, since that's how
> boolean =E2=86=92 integer conversion works in PHP. I don't think we can a=
ssume
> that every single person who's written that line of code didn't check
> whether CURLOPT_SSL_VERIFYHOST was a boolean or integer option.
>
> > According to libcurl, CURLOPT_SSL_VERIFYHOST =3D> 1 is "not ordinarily =
a
> > useful setting".
>
> I agree, but I don't think we can start arbitrarily changing well
> defined type conversion behaviour for one corner case. The
> CURLOPT_SSL_VERIFYHOST option has been documented as expecting integer
> 0, 1 or 2 since at least April 2002 (and probably quite a bit earlier
> than that), complete with the meanings of each value =E2=80=94 there's on=
ly so
> much we can do to protect developers from themselves. (In fairness,
> the wording strongly recommending using option 2 only came in last
> August thanks to Ilia, but nobody should have been treating the option
> as a boolean option to start with.)
>
> Fundamentally, it's a bad API on the part of curl, but that's a
> separate issue. There's nothing stopping somebody proposing a saner
> API on top of libcurl (as Anthony did recently with the password
> hashing API atop crypt()).
>
> In summary, I'm against changing ext/curl here.
>
> I do have a couple of specific comments on elements of the patch
> itself in the event that the changed behaviour is wanted, but I'll
> post those on GitHub, since it's probably a better UI for that sort of
> granular discussion.
>
> Adam
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>