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