Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70707 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 79230 invoked from network); 17 Dec 2013 13:44:48 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Dec 2013 13:44:48 -0000 X-Host-Fingerprint: 80.4.21.210 cpc22-asfd3-2-0-cust209.1-2.cable.virginm.net Received: from [80.4.21.210] ([80.4.21.210:16673] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 18/8E-32483-F4550B25 for ; Tue, 17 Dec 2013 08:44:48 -0500 To: internals@lists.php.net,Ferenc Kovacs Message-ID: <52B0554C.2080601@php.net> Date: Tue, 17 Dec 2013 13:44:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 References: <52AFABF7.60105@sugarcrm.com> <52B004E2.30607@php.net> <52B041E5.9070903@php.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 80.4.21.210 Subject: Re: [PHP-DEV] [VOTE] TLS Peer Verification From: krakjoe@php.net (Joe Watkins) On 12/17/2013 12:36 PM, 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 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. > Maintenance is not a real problem, and not necessarily our problem even. Some simple ideas; add an option to cli to update either using curl's or host our own, surely a bit of text manipulation is not beyond us ... package maintainers are capable of adding a cronjob, this is a complete non-issue. All encrypted client streams enable peer verification by default. This _of course_ breaks compatibility, if I decide to make an HTTPS request right now and don't change any settings it will work, insecurely, unverified, but it _will work_; you are proposing to break that by changing the default, and not include the data that fixes it ... this doesn't make any sense, it especially doesn't make any sense to say that this is in any way compatible, it is not. Cheers Joe