On Tue, Dec 17, 2013 at 3:02 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> On 12/17/2013 08:56 AM, Ferenc Kovacs 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.
>
> Note that the distro maintainers tend to hate when we bundle stuff like
> this. We have this same situation with the Olsen tz. They much prefer
> having a single place to update resources that are needed by multiple
> applications like the ca cert bundle and the Olsen tz db. So, for most
> of our users (assuming most of our users rely on distro-packaged
> versions of php) I don't think it actually matters whether we ship the
> ca bundle or not. The distros are going override this decision and point
> to the distro-level bundle much like many of them have done with the
> timezone file.
>
> -Rasmus
>
True, distros would prefer their own bundle, what I was saying above, that
even though most people would be covered by the distros, there will be
people, who will notice the BC break: either because they roll their own
php or because they use a distribution which doesn't provide a CA by
default, or ultimately because they are sites out there, which uses certs
not signed by CAs included in the major CA bundles.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu