[Ksummit-2013-discuss] [ATTEND] stable trees and pushy maintainers; cgroups interface; hid; depth of maintainers tree

[Theodore Ts'o]

On Tue, Jul 16, 2013 at 11:04:19AM +0200, Jiri Kosina wrote:
> - this doesn't seem to be explained *anywhere* in the changelog (please 
>   correct me if I am wrong), and therefore completely invisible to 
>   consumers of -stable branch, who are just going to be "ok, nice 
>   /dev/random rework, but what the heck is it doing in -stable"?

I plead guilty to this one.  Even if we didn't want to go into great
detail for security reasons, the explanation of why this patch was
necessary in terms of other changes to the entropy gathering code
would have been a good idea.

> - was the rush really necessary? If I got the dates right, 3.6 (containing 
>   big part of this) was released Sep 30th, first stable to contain this 
>   was 3.0.41, released Aug 15th. With such a huge rework, it was likely 
>   that there will be bug (and there indeed was). If the patches were kept 
>   in mainline for a little longer, the bug will probably be fixed there, 
>   and only then folded properly into -stable.

I wasn't the one who pushed for these changes to be pushed to stable,
so I can't speak authoratatively on what was the reason to get them to
-stable.  I assume that because it was considered a security problem,
people thought there was urgency.  In retrospect, it probably would
depend a lot on who was using the stable tree; it has a lot of
customers.  If the goal was to make sure that various embedded device
manufacturers might pick up the changes, it's much more likley that
they would pick up changes from 3.0.40 to 3.0.41, than to jump to 3.6.

OTOH, for enterprise distro kernels, most of those systems have plenty
of entropy through other means, so perhaps it wouldn't be that
critical.  (Of course, many of the traditional enterprise distro
companies are now dabbling with varying degrees of seriousness in the
embedded/mobile/handset market, so maybe they would have wanted it
anyway.)

>   But as it has been done this way, the bug was first discovered in 
>   -stable and only then fixed in Linus' tree. To me, this clearly sounds 
>   like failure of -stable process.

They hit Linus's tree before v3.6-rc1 (which was released on August
2nd).  That means it's not a failure of the -stable process, since
they were in Linus's tree before 3.0.41 came out on August 15th. 

If you want to argue that patches shouldn't hit -stable until Linus
releases a 3.x.0 final release containing the commits, that's a
different argument; and we can have that discussion (I think it
depends on the commit, myself) but what happened was consistent with
the process in place at the time.

>   The buggy keys are spread all over the Internet already anyway, so 
>   fixing this "now" or a 3 weeks later after much more testing is 
>   performed doesn't really provide any additional security benefit anyway.

Sure, but if we could get them out to embedded manufacturers sooner,
before they cut a snapshot for devices targetting the Christmas gift
buying season, I can see why there might be some urgency for getting
it pushed to 3.x in a hurry.  I wasn't involved with those
discussions, though, so I don't know whether or not there was some
reason why there was urgency to get them out to the stable kernels, or
this was a case of "it's post -rc1, let's get all of the bug fixes
that were justy merged pushed to stable ASAP!"

Regards,

						- Ted