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.
Yes, I have a couple more examples very similar to this one, but I didn't
want to initiate paralllel discussions about technical aspect of those
very patches, as I think the common part is the same -- proper
justification for -stable inclusion of each and every patch.
Thanks,
--
Jiri Kosina
SUSE Labs
--
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