On 18/02/11 at 17:24 -0500, Michael Gilbert wrote: > On Mon, 7 Feb 2011 22:54:53 -0500 Michael Gilbert wrote: > > On Sun, 6 Feb 2011 21:58:08 -0400, Joey Hess wrote: > > > Michael Gilbert wrote: > > > > Another issue was that a lot of vulnerabilities that were found in that > > > > time frame were actually flaws in new kernel code, so testing/unstable > > > > were vulnerable, but the stable kernel itself was unaffected, so it was > > > > a bit safer to be running the stable kernel since the code was older > > > > (i.e. there was more time to find and fix issues). For example, the > > > > vulnerability for one of the local privilege escalations that was > > > > exploited in the wild was introduced in 2.6.30, so lenny wasn't > > > > affected, but testing/unstable were. > > > > > > LWN's analysis of age of introduction of kernel security holes in 2010 > > > doesn't seem to agree? http://lwn.net/Articles/410606/ > > > > > > | So, in a sense, the above-mentioned kernel hacker was correct - an > > > | awful lot of the vulnerabilities fixed over the last year predate the > > > | git era, and are thus over five years old. > > > > LWN's analysis is far from comprehensive, and the conclusions are not > > based in sufficiently rigorous analysis, but instead on the usual > > numbers game. Their reporting is however very useful as a basis for > > further research. > > > > The first fact that they completely miss is that not all CVEs are > > created equal. A memory info disclosure gets a CVE just like a > > privilege escalation that has known exploits, but both are on the same > > playing field in the numbers game. Annecdotally, CVE-2010-3301 and > > CVE-2010-1146 had an exploit in the wild, and 2.6.26 was never > > affected. The only issue that had an in-the-wild exploit affecting > > lenny in that list (that I'm aware of) was CVE-2010-3081 (and lenny > > would have sidestepped that too if it had had been even more > > conservative and gone with the older/stabler 2.6.25). > > > > Even playing the numbers game with a bit more thoughtful analysis with > > the LWN data, lenny looks a lot better. It can be seen that lenny > > (2.6.26) was vulnerable to 69% (36 out of 52) of the vulnerabilities > > listed there, and squeeze (2.6.32) was vulnerable to 98% (51 out of > > 52). In my opinion that's a rather substantial difference, and thus a > > problem worth pondering. > > So, now that I've had some time to contemplate the replies on this > issue, I have a much better appreciation of the need to keep unstable > closely in line with upstream development, and thus don't want to push > the original solution anymore. Also 2.6.37 is in unstable now, so that > idea is impossible, which is OK. > > However, as I justify above, there is still a problem, and I think it > can still be solved relatively easily and without too much impact. > This time I suggest blocking 2.6.37 so 2.6.32 remains in testing for a > while. This will allow it to get updates in sync with stable kernel > security updates (without any additional effort by Dann, Moritz, and > other kernel team members other than the package upload to testing as > well).
You base your reasoning on the assumption that CUT users prefer a more stable kernel to a more recent kernel. I'm tempted to think the opposite. - lucas -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110219064759.ga30...@xanadu.blop.info
