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