Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70705
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH-PCH5Hnm0TBQSs+DCF2xLVoUY1QeNqWMBnb1Y6JkKvP9_dBA@mail.gmail.com>
References: <CAH8Mpn=W6cuZtn5210+u7xZ+ejM22mk0Sq3tihbQ0qRtr-H=LA@mail.gmail.com>
	<52AFABF7.60105@sugarcrm.com>
	<CAH8MpnnuSh1RJ8=Ty8rhEqg1mfGdJD+hs63zm7jBR66iXYaVXg@mail.gmail.com>
	<52B004E2.30607@php.net>
	<CAH-PCH6vYL6jmCd-D=3qxTV_pqP_-9Qd2rENGtDENfS8i=6Qiw@mail.gmail.com>
	<CAH8Mpnnbdn+hXw5R=m-qWexOmgR3+deSEE5a0vKhOQ=Rjf5egw@mail.gmail.com>
	<52B041E5.9070903@php.net>
	<CAH-PCH5Hnm0TBQSs+DCF2xLVoUY1QeNqWMBnb1Y6JkKvP9_dBA@mail.gmail.com>
Date: Tue, 17 Dec 2013 08:19:36 -0500
Message-ID: <CAH8Mpnn2pYVXs6o7mYMqBo=cy6RwhkzCL==ivnTEFY-E4-EyVQ@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Joe Watkins <krakjoe@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e013a1d90b1abeb04edbac7fe
Subject: Re: [PHP-DEV] [VOTE] TLS Peer Verification
From: rdlowrey@gmail.com (Daniel Lowrey)

--089e013a1d90b1abeb04edbac7fe
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 17, 2013 at 7:36 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:

>
>
>
> On Tue, Dec 17, 2013 at 1:21 PM, Joe Watkins <krakjoe@php.net> wrote:
>
>> On 12/17/2013 12:08 PM, Daniel Lowrey wrote:
>>
>>> given that this is a security related change, one could argue that
>>>>
>>> security
>>>
>>>> fixes should be ok to go in a minor version, even if they break BC.
>>>>
>>>
>>> This was my thought process. In my mind the RFC is about improving
>>> security
>>> for users who don't know any better. I'm hoping to avoid the "Are we
>>> allowed to break BC?" discussion.
>>>
>>
>> Okay, but nobody is asking the question "are we allowed to break
>> compatiblity for no good reason", because it's a silly question.
>>
>>
>>
>>> Adding a CA file to the distribution is exceedingly simple, but this is
>>> not
>>> a silver bullet. For example, the Mozilla CA file used by cURL is usual=
ly
>>> updated three or four times a year. Even when bundling a CA file it wou=
ld
>>> only be a matter of time before a distribution's version was out of dat=
e.
>>> In the end we can only do so much before users must bear the weight of
>>> maintaining an acceptable level of security themselves.
>>>
>>>
>>>
>> So then bundle it, doing something is much better than doing nothing,
>> there are plenty of opportunities to update the cafile with minor versio=
ns,
>> the package maintainers will likely solve the stale cafile problem for u=
s
>> on the major distributions, when they see we are actually doing somethin=
g
>> about it ...
>>
>> It really does not seem sensible to purposefully break compatibility whe=
n
>> it can be retained easily, the vote is going to be split with no clear
>> outcome doing no good for anyone. Reduce the options to two if you want =
to
>> actually move forward.
>>
>> That's enough from me, gonna go find something to break :)
>>
>>
> Don't forget that bundling a CA file also means that take the burden of
> keeping it up-to-date to our shoulders.
> I'm not saying that we shouldn't do it, but if we do then we have to make
> sure that we understand the implications.
> Even if we take the "easy" path, and select an already existing CA bundle
> (eg. Mozilla), we have to make sure to always ship the up-to-date version
> and there could be events, when we would need to create a release only
> because some CA incident (like what happened with DigiNotar in 2011 which
> forced the everybody shipping CA bundles to update their bundle to remove
> this CA from it's list of trusted CAs).
> As I've said, I'm only stating this so everybody can understand the
> implications before voting.
>
> --
> Ferenc Kov=E1cs
> @Tyr43l - http://tyrael.hu
>


Regarding the alteration of voting options Joe requested ...

I do believe approving the patch without bundling a CA file is a valid
option. As Ferenc mentioned there are potential maintenance issues with
including a CA file and I do not feel comfortable forcing the hand of the
release managers on this point. The vote exists between "yes" and "yes with
a bundled file" for this reason to tease out what's best for PHP in this
scenario. Please make sure you understand the ramifications of your choice
before voting.

I do want to preemptively address the idea that not including a CA file
would somehow cause disastrous BC breakage. In my opinion this could not be
further from the truth. APIs are not changing. The return value is already
FALSE with a warning generated on a connection or transfer failure. Code
should already have error checking in place for this potential scenario
because socket transfers are never guaranteed (maybe your ethernet cable is
unplugged).

The only difference this patch makes is to expand the reasons why a
transfer can return FALSE with an E_WARNING to include "you're doing
something dangerous." As far as BC breakage goes, this is as
backward-compatible as a BC break could possibly be.

--089e013a1d90b1abeb04edbac7fe--