Re: [VOTE] TLS Peer Verification

On Tue, Dec 17, 2013 at 7:02 PM, Joe Watkins <pthreads@pthreads.org> wrote: > On 12/17/2013 05:43 PM, Ferenc Kovacs wrote: > > > > > On Tue, Dec 17, 2013 at 5:23 PM, Joe Watkins <krakjoe@php.net> 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. -- Ferenc Kovács @Tyr43l - http://tyrael.hu