On Sunday, July 14, 2013 02:33:05 AM Jiri Kosina wrote:
> On Sat, 13 Jul 2013, Greg KH wrote:
>
> > > Ok, so as this topic seems to have gotten quite some traction even in
> > > other threads ("[Ksummit-2013-discuss] When to push bug fixes to mainline"
> > > etc), let me pick a rather random example for a case study (and yes, I
> > > personally had to suffer with that one quite a lot :) ).
> > >
> > > 3.0.41 has been released Aug 15 2012. It included a huge random.c update
> > > (upstream commits d2e7c96a, cbc96b75, c5857ccf, 00ce1db1a, c2557a303,
> > > e6d4947b12, a2080a67a, 902c098a, 775f4b29, 2dac8e54f, 3e88bdff,
> > > 3e88bdff1c, cf833d0b, 63d7717).
> > >
> > > Many of these went into Linus' tree for 3.6, which was released Sep 30
> > > 2012. 3.0.41 was released Aug 15 2012 (which is before final release of
> > > 3.6) (I hope I got the dates right, I have never been really strong in
> > > history classess).
> > >
> > > 902c098a was buggy, wasn't marked for stable in the changelog, hasn't been
> > > present in single Linus' major release, and still has been merged into
> > > -stable already. Makes one wonder where did all the rush come from.
> > >
> > > Actually the whole series of commits seems (to a rather unbiased observer,
> > > such as myself) to be rather an improvement and forward-pushing
> > > development of a random subsystem. How does/did that qualify for stable?
> >
> > They came from a reported security problem against the kernel, and came
> > at the request of security@xxxxxxxxxx. You should have found out the
> > details from it from the "vendor-sec" list (it's called something
> > different now, I can't remember the name, sorry), I know someone from
> > SuSE is on that list.
> >
> > I think the problem was eventually given a CVE number, so you could
> > track it down that way, but I don't have access to my email archives at
> > the moment to verify this or not, sorry.
> >
> > The kernel security team should now be reporting all of these issues to
> > the vendor-sec mailing list, I know we weren't in the past, which was a
> > complaint that we resolved a few months ago because of issues just like
> > this one you have pointed out.
>
> Well, if there is something going really "fast track" into stable in
> random.c area, I definitely can imagine it's because of a security problem
> :)
>
> But which patch of the huge bunch fixes the problem is not clear
> immediately.
> Was the whole series really necessary?
>
> The problem we have actually encountered was 902c098a ... it's not obvious
> how that patch would be fixing any security related issue (strictly
> speaking, it could actually create a new security problem).
> It's not even closely tight to the rest of the patches in the series
> (supposedly some of those patches is fixing some particular CVE ...).
>
> So I still fail to see a proper explanation why 902c098a itself is
> included in the stable tree.
Well, please let me add my 2c here. :-)
This particular example has nothing to do with maintainers supposedly marking
too much stuff for -stable as it is about a commit that wasn't even released
by Linus in this form. And that's *exactly* something I think should be
avoided in -stable if at all possible: commits that have no direct mainline
counterparts.
So even if something is marked for -stable by a maintainer or requested to be
included into -stable by someone, but it depends on some new material that
would need to be backported, *that* is the most risky thing for -stable
inclusion, because it may introduce bugs into -stable that have never been
present in the mainline. And that is a *disaster*. It's not just an
"oh, sh*t happens" thing, it's a failure of the whole process, because if
-stable has bugs that the mainline has never had, it's better to always use
the mainline.
I don't honestly think that simple fixes in -stable hurt anyone, as long as
they really *are* simple (especially if they have been cherry-picked directly
from the mainline). What hurts poeple is things like the above.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html