Gentoo Archives: gentoo-security

From: "Israel G. Lugo" <israel.lugo@×××××××.com>
To: gentoo-security@l.g.o
Subject: Re: [gentoo-security] Re: Kernel Security Update Target Delay?
Date: Sun, 17 Oct 2010 18:04:57
Message-Id: 4CBB39A4.6030600@lugosys.com
In Reply to: Re: [gentoo-security] Re: Kernel Security Update Target Delay? by Alex Legler
1 On 10/17/2010 04:51 PM, Alex Legler wrote:
2 > Er, who here assessed the issue to be not "important"?
3 >> [...]
4 > You seem to be assuming that we (=Gentoo people) live in a dream world
5 > and still need to be told about hackers and the need for IA32-emul code
6 > even today. We don't. So please stop discussing such banalities we are
7 > all well aware of and instead get to the point.
8 >
9
10 My remarks were not aimed at you (Alex) or the Gentoo security team in
11 particular. I was responding in general to several comments made both
12 in-list and on the bug. To name an example: "And the bug is not that
13 dangerous - except when you insist on running unsecure 32bit software on
14 a 64bit system." (Volker Armin Hemmann)
15
16
17 > No one claims that workarounds or mitigations are equivalent to a fix in
18 > the source code.
19
20 Through the process of the bug report and discussions on -security and
21 -hardened, it appeared to be the point of view of some people that this
22 wasn't a big deal, because of the Grsecurity workarounds that were
23 present. I was trying to argue that relying on that is dangerous and,
24 more importantly, that gentoo-sources never benefited from such workarounds.
25
26
27 > Yes, the Security team are the first ones to want things (properly)
28 > fixed, however we cannot just jump in and fix things. We have to work
29 > with maintainers and arch teams. This issue clearly has shown that there
30 > are frictional losses that need to be addressed.
31
32 That was my intended point.
33
34 As I tried to clarify on my second email (which I sent before receiving
35 your reply, and perhaps you only received it after replying), I am *not*
36 suggesting that Gentoo devs are incompetent, negligent, or otherwise
37 unqualified. My intentions were constructive; I've actually defended
38 Gentoo against several people over this, and it's frustrating to see
39 others making unfortunate public comments such as "Gentoo sucks, I'm
40 glad I changed to another distro", when the situation could have been
41 avoided altogether.
42
43 My concern is precisely because I appreciate the effort you (Gentoo
44 devs) place in your work, and this situation has created problems where
45 there shouldn't be. As a result, users were left vulnerable to a serious
46 exploit for a long time (as we all know, even 1 or 2 days may be more
47 than enough for a multiuser server to be compromised), something which
48 you obviously strive against. Also, the Gentoo public image of security
49 will have suffered by comparison, at least among those who follow CVEs
50 and security announcements. I'm sure you must be the first people who
51 don't want this to happen, so it's important to try and improve things
52 for next time.
53
54
55 > [several constructive remarks about improvements for the future]
56
57 I agree with everything you said here, and am glad to see something
58 positive come out of all this.
59
60 I agree that communication is key, and everyone would benefit from an
61 increase there. There are times when the established procedures may be
62 too rigid (dev makes a commit, makes formal request for testing, QA
63 tests, makes formal stabilization happen, etc.), especially in matters
64 of urgency such as with security response. Improved communication can
65 make things happen more smoothly, and perhaps it might not be a bad idea
66 for the necessary people to meet and try to reach a simpler process,
67 still valid but requiring a little less bureaucracy, for these kinds of
68 situations. In that respect, a kernel bug best-practices document might
69 very well help.
70
71 Best regards,
72 Israel