Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70709
Return-Path: <rasmus@lerdorf.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 85593 invoked from network); 17 Dec 2013 14:02:46 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 17 Dec 2013 14:02:46 -0000
Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown
Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.161.178 cause and error)
X-PHP-List-Original-Sender: rasmus@lerdorf.com
X-Host-Fingerprint: 209.85.161.178 mail-gg0-f178.google.com  
Received: from [209.85.161.178] ([209.85.161.178:59131] helo=mail-gg0-f178.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 47/8F-32483-38950B25 for <internals@lists.php.net>; Tue, 17 Dec 2013 09:02:44 -0500
Received: by mail-gg0-f178.google.com with SMTP id n5so106006ggj.9
        for <internals@lists.php.net>; Tue, 17 Dec 2013 06:02:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
         :cc:subject:references:in-reply-to:content-type
         :content-transfer-encoding;
        bh=e0CjPp+5aau38Eu49kzeW1WHjG27TfBZhwjmPy27hBo=;
        b=HppdtaJ2O0OF8FG82UDW1lP/MkESxzoxSEe2EP35qkMBMDXev0/74wVcmXrrD0kGiv
         PCviXY0Wrhp/EBht0d5bzjtxOPX9sxaL/TdHxfuLBumAybKmji8Q/AUcqnpHuIoJv3eX
         rLPM2Ppsj1g4OyrZwB6anIAZ6pqz0Us2HSe8aEG5i0sLDTsf+JFZEkHz5W5qb92J5OC0
         zY/8GiBCZTWBnZbQa1f6aFuT2WmN+n715kURaSc7RmPNCx21GPLqQGQCTcFlWS4VuYPA
         /YaYtM5qd0HJk8sO9Fju9y0oDipCkB3Lf9WJZSN/tS18Q2ESe42jE0lnptnlEzthv222
         hOrw==
X-Gm-Message-State: ALoCoQlZXkMaJeliLxECO0+GSdAquAqa5awziZG2OrXF7AxO8+MGFpxKCXRSdNpcVi9w26+hqaKP
X-Received: by 10.236.129.135 with SMTP id h7mr11486616yhi.75.1387288961379;
        Tue, 17 Dec 2013 06:02:41 -0800 (PST)
Received: from [192.168.1.100] (cpe-74-71-241-32.nyc.res.rr.com. [74.71.241.32])
        by mx.google.com with ESMTPSA id h23sm24573227yhc.0.2013.12.17.06.02.40
        for <multiple recipients>
        (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
        Tue, 17 Dec 2013 06:02:40 -0800 (PST)
Message-ID: <52B0597F.600@lerdorf.com>
Date: Tue, 17 Dec 2013 09:02:39 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ferenc Kovacs <tyra3l@gmail.com>, Daniel Lowrey <rdlowrey@gmail.com>
CC: Joe Watkins <krakjoe@php.net>, 
 PHP Internals <internals@lists.php.net>
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>	<CAH8Mpnn2pYVXs6o7mYMqBo=cy6RwhkzCL==ivnTEFY-E4-EyVQ@mail.gmail.com> <CAH-PCH43gLG_QpiioJkwYA0KqHpEwWNHwSQMhaHHbkvhgHU4vg@mail.gmail.com>
In-Reply-To: <CAH-PCH43gLG_QpiioJkwYA0KqHpEwWNHwSQMhaHHbkvhgHU4vg@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [VOTE] TLS Peer Verification
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 12/17/2013 08:56 AM, Ferenc Kovacs wrote:
> On Tue, Dec 17, 2013 at 2:19 PM, Daniel Lowrey <rdlowrey@gmail.com> wrote:
> 
>> 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
>>>>> usually
>>>>> updated three or four times a year. Even when bundling a CA file it
>>>>> would
>>>>> only be a matter of time before a distribution's version was out of
>>>>> date.
>>>>> 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 versions,
>>>> the package maintainers will likely solve the stale cafile problem for us
>>>> on the major distributions, when they see we are actually doing something
>>>> about it ...
>>>>
>>>> It really does not seem sensible to purposefully break compatibility
>>>> when 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ács
>>> @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.
>>
>>
> I wouldn't say it isn't a BC break, as there are a plenty of code out there
> which could/will break after this change.
> 
>    - If we don't ship/include a CA bundle, every stream connection for
>    ssl://, https:// or ftps:// resource will fail before the user changes
>    his/her php.ini
>    - even if we do include a CA bundle, there are a bunch of code which
>    connects to https:// urls using self-signed certs, and for some of
>    those, there is no CA file available, so you won't be able to get your code
>    functioning again without rewriting your code to explicitly disable peer
>    verification.
> 
> Those are BC breaks, and I'm pretty sure that this would/will affect a lot
> of users.
> But I do think, that in this case the BC break could be acceptable, so I'm
> looking forward to the results.

Note that the distro maintainers tend to hate when we bundle stuff like
this. We have this same situation with the Olsen tz. They much prefer
having a single place to update resources that are needed by multiple
applications like the ca cert bundle and the Olsen tz db. So, for most
of our users (assuming most of our users rely on distro-packaged
versions of php) I don't think it actually matters whether we ship the
ca bundle or not. The distros are going override this decision and point
to the distro-level bundle much like many of them have done with the
timezone file.

-Rasmus