| 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 |
Archives