On Tue, Dec 17, 2013 at 8:56 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>
>
>
> On Tue, Dec 17, 2013 at 2:19 PM, Daniel Lowrey <rdlowrey@gmail.com> wrote:
>
>> On Tue, Dec 17, 2013 at 7:36 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Tue, Dec 17, 2013 at 1:21 PM, Joe Watkins <krakjoe@php.net> 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.
>>>
>>> --
>>> Ferenc Kovács
>>> @Tyr43l - http://tyrael.hu
>>>
>>
>>
>> Regarding the alteration of voting options Joe requested ...
>>
>> I do believe approving the patch without bundling a CA file is a valid
>> option. As Ferenc mentioned there are potential maintenance issues with
>> including a CA file and I do not feel comfortable forcing the hand of the
>> release managers on this point. The vote exists between "yes" and "yes with
>> a bundled file" for this reason to tease out what's best for PHP in this
>> scenario. Please make sure you understand the ramifications of your choice
>> before voting.
>>
>> I do want to preemptively address the idea that not including a CA file
>> would somehow cause disastrous BC breakage. In my opinion this could not be
>> further from the truth. APIs are not changing. The return value is already
>> FALSE with a warning generated on a connection or transfer failure. Code
>> should already have error checking in place for this potential scenario
>> because socket transfers are never guaranteed (maybe your ethernet cable is
>> unplugged).
>>
>> The only difference this patch makes is to expand the reasons why a
>> transfer can return FALSE with an E_WARNING to include "you're doing
>> something dangerous." As far as BC breakage goes, this is as
>> backward-compatible as a BC break could possibly be.
>>
>>
> I wouldn't say it isn't a BC break, as there are a plenty of code out
> there which could/will break after this change.
>
> - If we don't ship/include a CA bundle, every stream connection for
> ssl://, https:// or ftps:// resource will fail before the user
> changes
> his/her php.ini
> - even if we do include a CA bundle, there are a bunch of code which
> connects to https:// urls using self-signed certs, and for some of
> those, there is no CA file available, so you won't be able to get your code
> functioning again without rewriting your code to explicitly disable peer
> verification.
>
> Those are BC breaks, and I'm pretty sure that this would/will affect a lot
> of users.
> But I do think, that in this case the BC break could be acceptable, so I'm
> looking forward to the results.
>
>
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>
Just to clarify: I'm not saying it isn't a BC break. I'm saying that:
1. As BC breaks go this one is extremely mild;
2. I believe this is a security question that's important enough to answer
with a BC break;
3. People have the option (through the vote to bundle a CA file) to
influence how far-reaching the resulting BC break actually is.