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

[Jiri Kosina]

On Sat, 13 Jul 2013, Theodore Ts'o wrote:

> > 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.
> 
> The specific reason for these changes was the following research work:
> 
> 	https://factorable.net/
> 
> In order to deal with this, we needed to sample randomness
> unconditionally for every single interrupt.  Historically, kernel
> developers had been very hesitant to sample for randomness because of
> the potential performance hit.  As a result, most of the drivers
> didn't sample for randomness, with the result shown above.  The fix
> was to sample for randomness unconditionally; commit 902c098a was to
> eliminate the performance impact of always sampling for randomness.

Hi Ted,

thanks for explanation. This unfortunately brings more questions / 
remarks, namely:



- 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"?

  This actually connects to the complaints of some folks from our beloved 
  "security community" (spender, for example). I agree that their 
  arguments are very often overboard, as it's not really easily possible 
  to evaluate whether each and every patch has security implications.
  But here, the situation seems to be different -- it was known from the 
  very beginning that this all is security related, all the rework has 
  been done with this in mind, but I fail to see proper background in changelog.

- 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.

  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.

  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.

Please, don't get me wrong. I am not targetting this very patchset 
specifically. I am just trying to point out why sometimes our life with 
-stable is difficult, and I think it doesn't necessarily have to be.

Thanks,

-- 
Jiri Kosina
SUSE Labs