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