Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70719
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52B091BF.7050200@pthreads.org>
References: <CAH8Mpn=W6cuZtn5210+u7xZ+ejM22mk0Sq3tihbQ0qRtr-H=LA@mail.gmail.com>
	<52AFABF7.60105@sugarcrm.com>
	<CAH8MpnnuSh1RJ8=Ty8rhEqg1mfGdJD+hs63zm7jBR66iXYaVXg@mail.gmail.com>
	<52B004E2.30607@php.net>
	<CAH-PCH6vYL6jmCd-D=3qxTV_pqP_-9Qd2rENGtDENfS8i=6Qiw@mail.gmail.com>
	<52B03511.8040603@php.net>
	<CAH-PCH7mUQOZgdkZtZJC=6ASWPk5cYSSzX0AJXWCKfuFrhJ3MA@mail.gmail.com>
	<52B03ADB.9050703@php.net>
	<52B07689.9010505@ajf.me>
	<52B07A6C.9090305@php.net>
	<CAH-PCH65BcWNkjdsG9UcOPZZk02qqpo=Av1=wTFct_Ptt5sT3A@mail.gmail.com>
	<52B091BF.7050200@pthreads.org>
Date: Tue, 17 Dec 2013 19:20:55 +0100
Message-ID: <CAH-PCH5MBiorG6XV1w8x0sp=ejAddx7G0wOLz-O1js=GEMQGqw@mail.gmail.com>
To: Joe Watkins <pthreads@pthreads.org>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b6731b24bc8cb04edbefdde
Subject: Re: [PHP-DEV] [VOTE] TLS Peer Verification
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7b6731b24bc8cb04edbefdde
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 doe=
s
>> not and should not mean changing the behaviour of code unless that is th=
e
>> 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 fr=
om
> 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.html=
distros try to wrap that away, which can cause bugs like this:
> https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/92075=
8
> 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=C3=A1cs
> @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 becaus=
e
> 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 everythin=
g
> to function properly, even if it's overridden that shouldn't be our
> concern, we should just concern ourselves with distributing working sourc=
e
> 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.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7b6731b24bc8cb04edbefdde--