1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
At the moment, we don't have an accepted and documented way to handle |
5 |
Kernel CVEs. Right now, they're just being filed and then maybe being |
6 |
resolved when upstream commits a patch. |
7 |
|
8 |
I believe we need some way of judging priority and severity of kernel |
9 |
vulnerabilities to improve bug handling and make sure that we stay |
10 |
up-to-date with current patches being released. Linux kernel |
11 |
development is very fast paced, so we should set up a clear system, |
12 |
much like we have right now for packages in Portage, to facilitate the |
13 |
filing and management of these bugs. |
14 |
|
15 |
I'm not really a kernel guy, but there are some things that I can |
16 |
figure out and propose without knowing much about kernel internals. |
17 |
First, we could classify priority (giving it a letter grade) by |
18 |
considering whether the issue is in kernel code that is enabled by |
19 |
default, or whether the user has to enable the vulnerable code in the |
20 |
kernel config. We could also use the tilde (~) as a grade when the |
21 |
vulnerable code is marked EXPERIMENTAL in the config, much like we do |
22 |
for unstable packages. |
23 |
|
24 |
As far as severity goes, I think that severity would be similar to |
25 |
what we have at the moment for packages, with maybe some minor |
26 |
improvements to make the descriptions relevant. Priority and severity |
27 |
could then be translated to an appropriate Whiteboard grade for better |
28 |
tracking. |
29 |
|
30 |
We need to develop and agree on solid criteria so that bug wranglers |
31 |
can classify security issues efficiently. |
32 |
|
33 |
Since the general workflow for handling kernel issues is report to |
34 |
upstream -> patch -> patch included in next release, we can have three |
35 |
statuses in the Whiteboard field to represent these. Just as a |
36 |
proposal, those could be "upstream" and "patch", and then close the |
37 |
bug as Resolved Fixed when the next version is released. An |
38 |
alternative is to close the bug when the patch is committed to the |
39 |
kernel repositories instead of when the next version is released. |
40 |
|
41 |
Something else to consider is whether GLSAs will be released after a |
42 |
release is available. I have varying opinions on the matter, as while |
43 |
the Kernel is not a part of Gentoo persay, it is still a security |
44 |
issue that should be reported to users and spread for wide |
45 |
distribution. I'm open to opinions on this matter. |
46 |
|
47 |
- -- |
48 |
Samuel Damashek |
49 |
-----BEGIN PGP SIGNATURE----- |
50 |
Version: GnuPG v2.0.22 (GNU/Linux) |
51 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
52 |
|
53 |
iQEcBAEBAgAGBQJSzLIsAAoJEGw+uP08RytWQ+cH/3w/0hWEWupYJGbQD5/LSqzm |
54 |
fT8BD5hdYyN53wmYLopAs9pLJ4spaVxJBCY6xGaabWCEC1PgoQiIQ1URh4Bmekei |
55 |
Z/6ruNSMcBStV+ATJPN2pawz28/ByFEIWjEECGNhInx/DnmbCoNASZ9d728kw1TK |
56 |
gYbCg/FkOMn333+KmU0Q8QyxIB30gi6ApbD0SBKUwtHVVNOUnbHfo4YAbNypBN2m |
57 |
xQjmNMlYDWUyTSq6+8II9zQk0zDPo5GC1TRW6f1/Jw6B/wh5IbCir9qaVMdRi+S8 |
58 |
nUKqkhMXhJJuXEmmYWKgxFFhnVFBwPYH3MuSuxG+UUN7u7yuPI5PycCRlagVSD4= |
59 |
=DFua |
60 |
-----END PGP SIGNATURE----- |