Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70720 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 30722 invoked from network); 17 Dec 2013 18:33:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Dec 2013 18:33:52 -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:24759] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FD/24-32483-E0990B25 for ; Tue, 17 Dec 2013 13:33:51 -0500 To: internals@lists.php.net,Ferenc Kovacs Message-ID: <52B0990B.4010503@php.net> Date: Tue, 17 Dec 2013 18:33:47 +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> <52B03511.8040603@php.net> <52B03ADB.9050703@php.net> <52B07689.9010505@ajf.me> <52B07A6C.9090305@php.net> <52B091BF.7050200@pthreads.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 06:20 PM, Ferenc Kovacs wrote: > On Tue, Dec 17, 2013 at 7:02 PM, Joe Watkins wrote: > >> On 12/17/2013 05:43 PM, Ferenc Kovacs wrote: >> >> >> >> >> On Tue, Dec 17, 2013 at 5:23 PM, Joe Watkins wrote: >> >>> On 12/17/2013 04:06 PM, Andrea Faulds wrote: >>> >>>> >>>> >>>> On 17/12/13 11:51, Joe Watkins wrote: >>>> >>>>> I'm saying that we should, definitely, accept the patch; in this >>>>> specific case we can fix the implementation or security issue without >>>>> affecting behaviour, >>>>> >>>> >>>> Unfortunately that's not true. To fix the security issue REQUIRES >>>> affecting behaviour. Otherwise it's not fixed. >>>> >>>> >>> If the CA file is present with verification enabled the vast majority >>> of requests will execute as they do now, but securely. Most of the time, no >>> evident change. If the CA file is not present change is introduced, lots of >>> it. >>> >>> Changing the behaviour of the language from an internals perspective does >>> not and should not mean changing the behaviour of code unless that is the >>> intention behind the change, obviously. >>> >>> >>> Cheers >>> Joe >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >> Yes, as I mentioned shipping a CA file would help some users (we can only >> guess here, but I think most users would be using the shared CA bundle from >> their distro, and only a small percentage would use the one that we >> provided). >> >> On the other hand everybody else apart from the browsers seems to be >> trying to *not* ship their own CA bundle anymore. >> Python doesn't ship one (even though it was requested: >> http://bugs.python.org/issue13655) >> Ruby doesn't ship one. >> Java has it's own: >> http://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.htmldistros try to wrap that away, which can cause bugs like this: >> https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/920758 >> Perl doesn't ship one, but has multiple cpan modules which provide CA >> bundles. >> >> I stopped looking, but I really think that we should refrain from >> shipping a CA bundle and take the burden of maintenance to ourselves. >> >> -- >> Ferenc Kovács >> @Tyr43l - http://tyrael.hu >> >> >> I'm not sure it's really relevant; since we don't know what position they >> were in when they started to reference the CA file properly. >> > > Not sure what you are trying to say here. > > >> This is the strange way round to do it, it would be a no brainer if we >> were just introducing the support for ssl requests, but we're not. >> > > Yeah, then it wouldn't be a BC. > > >> >> It's similar to saying that we shouldn't provide a default php.ini because >> they are always always always overridden, everywhere. >> > > We are the php project, we are one of the best group of people to provide > default php.ini settings. > On the other hand we have 0 experience of managing root CA lists, and there > are people out there already, who are already doing that (shipping CA > bundle). > A better example would be pspell: using it you need a dictionary, but we > didn't ship that, we trust the user to have them. > > >> It doesn't make sense to provide less than what is required for everything >> to function properly, even if it's overridden that shouldn't be our >> concern, we should just concern ourselves with distributing working source >> code, as always, package maintenance is nothing to do with us. >> > > CA bundle isn't source code, we don't need it, users to, it isn't necessary > our job to provide them with, and most of the other project seems to put > this "burden" to the user/distro. > Well, we weren't actually discussing managing it, just distributing it. I think the number of times it will really need management is so low that it's not really worth discussing if there is a sane plan of action in place, which is not that difficult or problematic. I am just repeating myself, I know it is not source code, the point is that, before the patch, you can compile php and get on with business and nothing strange will happen, after the patch, the same behaviour requires data we apparently don't want to distribute ... I'm not saying we should accept the burden of prolonged maintenance necessarily just provide a sensible default, one that works the same after the patch as it does before, since it's not hard to achieve. Cheers Joe