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.