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 |