On 10/17/2010 04:51 PM, Alex Legler wrote:
> Er, who here assessed the issue to be not "important"?
> You seem to be assuming that we (=Gentoo people) live in a dream world
> and still need to be told about hackers and the need for IA32-emul code
> even today. We don't. So please stop discussing such banalities we are
> all well aware of and instead get to the point.
My remarks were not aimed at you (Alex) or the Gentoo security team in
particular. I was responding in general to several comments made both
in-list and on the bug. To name an example: "And the bug is not that
dangerous - except when you insist on running unsecure 32bit software on
a 64bit system." (Volker Armin Hemmann)
> No one claims that workarounds or mitigations are equivalent to a fix in
> the source code.
Through the process of the bug report and discussions on -security and
-hardened, it appeared to be the point of view of some people that this
wasn't a big deal, because of the Grsecurity workarounds that were
present. I was trying to argue that relying on that is dangerous and,
more importantly, that gentoo-sources never benefited from such workarounds.
> Yes, the Security team are the first ones to want things (properly)
> fixed, however we cannot just jump in and fix things. We have to work
> with maintainers and arch teams. This issue clearly has shown that there
> are frictional losses that need to be addressed.
That was my intended point.
As I tried to clarify on my second email (which I sent before receiving
your reply, and perhaps you only received it after replying), I am *not*
suggesting that Gentoo devs are incompetent, negligent, or otherwise
unqualified. My intentions were constructive; I've actually defended
Gentoo against several people over this, and it's frustrating to see
others making unfortunate public comments such as "Gentoo sucks, I'm
glad I changed to another distro", when the situation could have been
My concern is precisely because I appreciate the effort you (Gentoo
devs) place in your work, and this situation has created problems where
there shouldn't be. As a result, users were left vulnerable to a serious
exploit for a long time (as we all know, even 1 or 2 days may be more
than enough for a multiuser server to be compromised), something which
you obviously strive against. Also, the Gentoo public image of security
will have suffered by comparison, at least among those who follow CVEs
and security announcements. I'm sure you must be the first people who
don't want this to happen, so it's important to try and improve things
for next time.
> [several constructive remarks about improvements for the future]
I agree with everything you said here, and am glad to see something
positive come out of all this.
I agree that communication is key, and everyone would benefit from an
increase there. There are times when the established procedures may be
too rigid (dev makes a commit, makes formal request for testing, QA
tests, makes formal stabilization happen, etc.), especially in matters
of urgency such as with security response. Improved communication can
make things happen more smoothly, and perhaps it might not be a bad idea
for the necessary people to meet and try to reach a simpler process,
still valid but requiring a little less bureaucracy, for these kinds of
situations. In that respect, a kernel bug best-practices document might
very well help.