Hi, Now that squeeze is released, I've started thinking about how to improve the quality of security support for testing.
The biggest problem I saw during the squeeze development cycle was that kernel security update transitions were extremely slow due to unrelated RC bugs. This was bad since it left testing users vulnerable to issues for much larger periods of time than stable/unstable users. 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. I'd like to propose a solution to these two problems: only upload known rock solid longterm cadence upstream supported kernels into testing/unstable. This will hopefully reduce the amount of transition delay since the longterm kernels should have fewer RC issues (after they've had a little time to cook of course). There are, of course, some undesirable consequences to this plan. One is that a certain subset of testing users expect the latest shiny all the time; but they can easily get their fix from the experimental kernels instead, so that isn't really a problem (I think). The second issue is that testing d-i will not support the latest and greatest hardware and features. I think this can be solved by providing two sets of d-i media for testing (one that uses the longterm testing kernel and one that uses newer experimental kernel). Of course this means that some d-i development will need to move to experimental to make use of the newer kernel feature, but I don't think that would really be a problem. A benefit to this proposal is that there will be reduced work for those currently supporting kernel security updates since the same package can be uploaded to both stable-security and unstable. Also, there should be no RC issues that prevent transitions to testing since for example the 2.6.32 kernel is so well-tested already. Anyway, I think this would go a long way toward improving the quality of security support in testing and thus reducing the common advice/meme that users should avoid testing if they're concerned about security. So, my proposal in a nutshell is to only upload upstream 2.6.32 point releases to wheezy/sid for the next 12-18 months. At that time, reevaluate and determine what the next longterm cadence kernel will be, and then once that is reasonable stabilized in experimental, finally upload it to unstable for the final stages of wheezy development (perhaps a few months before the freeze). Looking forward to thoughts and discussion on the matter. Best wishes, Mike Disclaimer: note that I haven't participated in kernel packaging or applied kernel security patches directly myself (yet), but I have been triaging and tracking kernel security issues for about a year and a half now [0], so I have a pretty good understanding of the status quo. [0] http://svn.debian.org/wsvn/kernel-sec/?op=log _______________________________________________ Secure-testing-team mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/secure-testing-team
