-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/08/2014 03:04 AM, Samuel Damashek wrote: > 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 agree that a way to handle kernel issues should be part of the Gentoo security process. Although following the LKML and relevant mailing lists, as well as the commits is probably too high a workload (for someone not already participating/following kernel development closely), action when a CVE is announced seems merited. > > 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. > An argument can be made that since it is not part of the "regular user experience update process", special care should be taken in announcing information regarding vulnerable versions, in particular for system administrators that sets up a large set of servers, often remotely. Based on own experiences at least it is easy to not update the kernel too often in fear of breakage. A way to communicate vulnerable versions seems merited if we want Gentoo to be used in these kinds of systems. That said, maybe not for all long term branches, would it be an idea to limit the "monitored versions" to a subset of the long term release branches? My initial thought would be to (at least initially) limit monitoring to 3.4 and 3.10 (currently two latest longterm branches), then maybe change the number whenever a new longterm branch is available. [a] However a policy is obviously required and there might be reasons to limit the announcements rather strictly based on the severity of bugs. Endnotes: [a] Personally I keep my servers on 3.4 series still at least - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Nil satis nisi optimum Nothing but the best is good enough -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJSzQxpAAoJEPw7F94F4TagdfMQAJIQTE4kwea+d48a2rdbBQ19 vThbZSLi0tbCiTERn8PVG4xGeVHQ5wyJKMBXK18le0AcU7fBrSh8vZclSi4v7r/v yFDo8lcvrOgxW/q6Pc4ESYP2To0ITOIOuOZxi7rDns/EgLdFOZGaf/gre/2huLtp N4xRPjSQXTdEINLYPYmATmyNEE7oafGjpjE4oG7f9hbjDrOyifv56/vyRM2p1j00 Q3kLf0v9g/oDnJj3+ufDhPQ877kbZHrq+ge9XadDKoJ1iDl3VY9UkfH4d3ehOSCW SpKS140GDjFAA62sKFKnwGzAmaRKJIxaaBgYJpKhaRgF9LuNAUFSHuH33Q1h9dtY P5umAUH5L/WcKLa6yMXlM5Pt5Xr5ofj2kB7QynqU/1U42Sm0ci/MjHTqlC5nFn85 fE7FpZAs1J9ddIdst7Rhpmk+2p+KfT7ET50NCLXEnJIPt0iR3/l+LPRA22tNMMwf MSmTU7OTgR+i7TTCYs2czgjuB/jpo4vf9Bg7J/j9cStsn1Xh7oy/AdqzVt8KlHCY x8nDMHoNSJuB+FqmDeMoRpWWpxNCnWj6DfnypRD02sdKrSB2dzZD0d0giP7WKX4k OaPmLiwxytq4G27RmShvOgCuu1YeodCng85YluZdzMYkSsP9j407+7Ye8qkwV7aa N3gZara1/O6oP1G5B7/M =08J3 -----END PGP SIGNATURE-----
