Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70710 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 87233 invoked from network); 17 Dec 2013 14:05:19 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Dec 2013 14:05:19 -0000 Authentication-Results: pb1.pair.com smtp.mail=rdlowrey@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=rdlowrey@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.181 as permitted sender) X-PHP-List-Original-Sender: rdlowrey@gmail.com X-Host-Fingerprint: 209.85.223.181 mail-ie0-f181.google.com Received: from [209.85.223.181] ([209.85.223.181:55778] helo=mail-ie0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6C/DF-32483-F1A50B25 for ; Tue, 17 Dec 2013 09:05:19 -0500 Received: by mail-ie0-f181.google.com with SMTP id e14so8363275iej.40 for ; Tue, 17 Dec 2013 06:05:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O0h8aCc0t57DJBytBS9neJw9dEsQo3qOKMtXgSSw7xE=; b=bxv8AhVi1Eamqok4mSE8hSObz0n2+RvyJ9QYfrFdJKVMt65+8KhA/wuBz/htVkVsdY GxLOp8aawZ6u6PILl597Z9Lm9/EoM3V8OUIC5S0l9dnSE4SEhP2hZsVwAOqzlbs+gceg 1jm/5AqIxLxbV3BWHuk5P1BB8O8RwjcyKVd+INEplZmYvtS2t13KsKaoRzsVOQ/zDBEz cqtXeQn/oh/UkzwZaG+95/8tm54zTIu1tNdP1REPTtL6a3x8fogLfyjnH2tUlIbYCuAj Ci+sNTfcWMEWGTy08mxq9gnfyTLL/r9Q+TY0EesEYbWoqFS2vdUJeWGQ/WTNhzQiTZPo noQw== MIME-Version: 1.0 X-Received: by 10.43.161.2 with SMTP id me2mr16819491icc.20.1387289116363; Tue, 17 Dec 2013 06:05:16 -0800 (PST) Received: by 10.50.208.105 with HTTP; Tue, 17 Dec 2013 06:05:16 -0800 (PST) In-Reply-To: References: <52AFABF7.60105@sugarcrm.com> <52B004E2.30607@php.net> <52B041E5.9070903@php.net> Date: Tue, 17 Dec 2013 09:05:16 -0500 Message-ID: To: Ferenc Kovacs Cc: Joe Watkins , PHP Internals Content-Type: multipart/alternative; boundary=001a11c2fa92fb53cb04edbb6ab4 Subject: Re: [PHP-DEV] [VOTE] TLS Peer Verification From: rdlowrey@gmail.com (Daniel Lowrey) --001a11c2fa92fb53cb04edbb6ab4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Dec 17, 2013 at 8:56 AM, Ferenc Kovacs wrote: > > > > On Tue, Dec 17, 2013 at 2:19 PM, Daniel Lowrey wrote= : > >> On Tue, Dec 17, 2013 at 7:36 AM, Ferenc Kovacs wrote: >> >>> >>> >>> >>> On Tue, Dec 17, 2013 at 1:21 PM, Joe Watkins 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 o= f >>>>> 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 vers= ions, >>>> the package maintainers will likely solve the stale cafile problem for= us >>>> on the major distributions, when they see we are actually doing someth= ing >>>> 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 wan= t 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-dat= e >>> version and there could be events, when we would need to create a relea= se >>> only because some CA incident (like what happened with DigiNotar in 201= 1 >>> which forced the everybody shipping CA bundles to update their bundle t= o >>> 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 th= e >> release managers on this point. The vote exists between "yes" and "yes w= ith >> 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 choi= ce >> 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 alrea= dy >> 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 pe= er > verification. > > Those are BC breaks, and I'm pretty sure that this would/will affect a lo= t > of users. > But I do think, that in this case the BC break could be acceptable, so I'= m > looking forward to the results. > > > > -- > Ferenc Kov=E1cs > @Tyr43l - http://tyrael.hu > Just to clarify: I'm not saying it isn't a BC break. I'm saying that: 1. As BC breaks go this one is extremely mild; 2. I believe this is a security question that's important enough to answer with a BC break; 3. People have the option (through the vote to bundle a CA file) to influence how far-reaching the resulting BC break actually is. --001a11c2fa92fb53cb04edbb6ab4--