1 |
On 10/17/2010 11:51 AM, Alex Legler wrote: |
2 |
> Excerpts from Israel G. Lugo's message of Sun Oct 17 15:59:15 +0200 2010: |
3 |
>> Your own |
4 |
>> vulnerability treatment policy ranks it as A1 level, and correctly so in |
5 |
>> my opinion. |
6 |
>> |
7 |
> |
8 |
> Besides the fact that the VTP is still not applicable to Kernel |
9 |
> packages, we now do seem to rank things correctly? Can you please make |
10 |
> up your mind? |
11 |
|
12 |
The VTP States: |
13 |
|
14 |
Currently kernels are not covered by the GLSA release process. |
15 |
Vulnerabilities must still be reported and will be fixed, but no GLSA |
16 |
will be issued when everything is solved. |
17 |
|
18 |
To me that sounds like we still do everything the same, but we don't |
19 |
publish a GLSA when we're done. It is then suggested that the reason |
20 |
for the policy is that we have shortcomings in our current tools. |
21 |
|
22 |
It does not sound to me like we just take care of kernel root exploits |
23 |
whenever we get around to it, as a matter of policy. |
24 |
|
25 |
If we do not officially support security updates on the kernel the |
26 |
webpage should be updated to explicitly state so. Of course, it would |
27 |
be better to actually have a sane security policy on the kernel, even if |
28 |
we can't make official GLSAs. Also, tool problems or not there is no |
29 |
reason we couldn't grant somebody rights to post to the GLSA mailing |
30 |
list so that they could send out manual notifications when serious |
31 |
kernel vulnerabilities are fixed. |
32 |
|
33 |
As it stands, a new gentoo-sources version was fixed, but the vulnerable |
34 |
versions remain in portage and are not masked, so even users who run |
35 |
emerge world often might not have realized that the need to upgrade |
36 |
their kernels (as in build and install them and not just have the |
37 |
sources lying around). I know I usually take my time on kernel upgrades |
38 |
waiting for opportune moments, unless there is a serious issue with the |
39 |
version I'm running. |
40 |
|
41 |
This isn't about blame-finding/etc. It would be nice to look at the |
42 |
overall process going forward and try to improve it. That starts by |
43 |
admitting that next time we'd like to do better. |
44 |
|
45 |
Rich |