Hi!
On Fri, Jul 11, 2014 at 12:54:09PM -0400, Alex Xu wrote:
> > - Gentoo is usually slower than other distributions on this, which is sad
> gentoo also has fewer devs and less manpower than other distributions,
> full stop.
Sure, that's why I've said it's just "sad".
> > - Hardened kernels are special ones - if people use hardened it means they
> > bothers about security more than average linux user
> true
> > so they more likely to accept the risks you mentioned
> false; if anything, they are *less* likely since they are likely running
> production systems.
There is a risk production won't boot or won't be stable with new kernel.
First one isn't risk at all, 'cos if it won't boot you'll immediately
notice this and just boot previous kernel instead - this won't even result
in noticeable interruption of your services (no more than usual when you
reboot to update kernel).
Second is a real issue, of course, but chances are it will show itself
several days or even weeks later, and it's really questionable is it good
idea to spend so much time testing new kernel "just in case" in this situation.
At same time there is a FACT (i.e. risk with 100% chance to happens) what
your production is vulnerable, and any user (or even someone with
webshell) is able to crash it or even get root and own it.
Consequences of this may be much more costly and painful than consequences
of new kernel's instability (which may happens days/weeks later) - this is
really depends on user, so ONLY USER really able to decide is it makes
sense for him to update kernel in this situation or not.
One more thing: even if kernel isn't stable, but it took days/weeks to
find this, then there is a good chance when (or even before) most users
notice this there will be available update which fix this issue.
> > - If you (I mean Gentoo devs in general, not personally you) didn't
> > release or stabilize such a critical security fix because of some
> > reasons (not well tested on some hardware, known to have issues on some
> > hardware, etc.) - I think you should ASAP release GLSA or news or
> > whatever (announcement in this maillist, at last) to force emerge to
> > notify users about EXACT REASONS why this security fix isn't stabilized
> > yet - to let THEM decide is these reasons apply to THEIR hardware and is
> > they ready to take such risk and update to ~ARCH (or at least give them
> > idea about when it expected to be stabilized and, if any, possible
> > recommendations how to temporary protect against this security issue
> > until new kernel will be stabilized)
>
> 1. we don't have enough people to release GLSAs as is, let alone
> continuous progress announcements.
ok, let's forget about GLSA.
> 2. if you want to spend that much time, follow upstream itself. any such
> "notifications" would merely serve to waste sec's time that could have
> been spent on actually stabilizing the package.
And how following upstream helps me in this situation? Linux kernel devs
already fixed this security hole and released new kernel; some other
distributions somehow quickly tested is and also released these new
kernels… but this doesn't mean Gentoo's hardened-patched kernel also
stable, and there is no "upstream" who knows about possible issues with
hardened kernel. So, who I should to follow?
> > Last point doesn't mean you should do extra work/research etc.
>
> yes, it does. by definition, doing more is more work.
No, it doesn't. When responsible Gentoo dev decide not to stabilize kernel
with critical security fix he (I suppose!) knows WHY he made this decision.
All I'm asking - to have him share these reason(s), in any way suitable
for him - if releasing GLSA is too complicates then he may write to
maillist or even tweet (I don't use Twitter, but I'll start if that will
be only channel to get such information). How many "more work" it took to
write an email or tweet each time after making (hard, I hope) decision to
not stabilize kernel yet comparing to all other work needed before making
that decision?
Again, my main point is: ONLY USER is able to assess the risks for HIS
production server, but to do this responsibly he should KNOW REASONS why
much more qualified gentoo devs decide to not stabilize this kernel yet.
Especially if there is no actual reason except "we didn't spend X days
waiting for possible bug reports" yet.
--
WBR, Alex.
