1 |
Carsten Lohrke wrote: |
2 |
|
3 |
> This is indeed a problem. But the user expects a single point of information |
4 |
> about vulnerabilities from a distribution - and he's absolutely right to do |
5 |
> so. |
6 |
|
7 |
No, the user expects a single information channel. If we release Kernel |
8 |
alerts (GLKAs) in the same media as GLSAs (gentoo-announce, forums and |
9 |
RSS feed) he will get both. We can even name them "GLSAs" if that makes |
10 |
you feel better. They just won't have the same contents and won't be |
11 |
used by the same tools (see my explanation about glsa-check dealing with |
12 |
installed packages rather than with currently used kernel). |
13 |
|
14 |
> KISS is fine, but only as additional source. Please don't see the |
15 |
> following as flaming, but: So for some reason we can't fix kernel issues in |
16 |
> time or at least not on all architectures - then it's probably better to send |
17 |
> out a GLSA that we drop these architectures security-wise or that we have |
18 |
> problems with fixing kernel vulnerabilities, noting them and ask people to |
19 |
> stop using distinct kernels or Gentoo at all in the worst case as long as we |
20 |
> cannot react in acceptabe time. |
21 |
|
22 |
Thing is, we can't fix all kernel issues in time for *any* source. By |
23 |
listing vulnerabilities rather than fixes, we : |
24 |
|
25 |
1- give accurate information about kernel security status to our users, |
26 |
better than any distribution |
27 |
2- show which sources get fixed and which don't, creating emulation |
28 |
between kernel source maintainers |
29 |
3- leave the choice to the user as to when he wants to upgrade his |
30 |
kernel, rather than force him to upgrade every week for some Local DoS |
31 |
that doesn't even affect him. |
32 |
|
33 |
We tried the old system, it just doesn't work. It may be a manpower or |
34 |
an organization thing, so you're free to come and take kernel security |
35 |
into your own hands if you feel you can do better than us. Kernel |
36 |
security is even more difficult to handle than Portage security : you |
37 |
will see that you don't get much user support (they don't enter bugs |
38 |
about kernel vulnerabilities at all) and will have to deal with |
39 |
reluctant kernel maintainers (they batch patches to keep the work |
40 |
manageable, and rightly so). |
41 |
|
42 |
How do other distributions fix this ? Debian doesn't do much kernel |
43 |
DSAs, Ubuntu/RedHat issue a kernel per month and have a dedicated (paid) |
44 |
one-source kernel security team. We chose to keep Gentoo choices |
45 |
(multiple sources with security information on them), innovate and |
46 |
propose more information to our users. |
47 |
|
48 |
Just wait and see how it works rather than saying it's insufficient. |
49 |
|
50 |
-- |
51 |
Koon |
52 |
-- |
53 |
gentoo-security@g.o mailing list |