On Sun, Jun 05, 2005 at 12:22:07PM +1000, Brian May wrote: > Whats the deal with bug #307900?
> As far as I can tell from reading the bug report, the bug has not been > fixed in sarge, will not be fixed for the release, but the bug has > been closed. kernel-source-2.6.8 2.6.8-15 has been in testing for some time now. kernel-image packages built against 2.6.8-16 are available in sarge for the past week or so for i386, alpha, and ia64. kernel-image packages built against 2.6.8-15 are also available in sarge for sparc; the amd64 kernels for the i386 architecture are also built against this revision. There are further security fixes in -16, so these images should be rebuilt, but they include the fix for 307900. Fixed kernel-image packages were not available for the other architectures prior to the freeze, so will need to be handled via security.debian.org. However, AIUI the exploit that exists in the wild for this hole is i386-specific (please correct me if I'm wrong). In light of the announcement at the beginning of May that sarge is security-supported, I think it would be a good idea for any DSAs issued over these holes to include mention of the relevant kernel versions for i386 etc., so that users who have upgraded earlier know that they need to upgrade and reboot. Most of the architectures that are still shipping unfixed 2.6.8 kernels in sarge are outside the purview of the kernel team AIUI, so it may take a bit of time to get packages synced up for a DSA. > Have we come to the point where making a release is more important > then fixing known security bugs? What is known is that new security holes that affect sarge have been appearing on a roughly weekly basis, and new security holes affecting the kernel are being reported on a roughly monthly basis. You can't get to a release with no known security holes using those kinds of numbers; you can pick and choose *which* security fixes you think are important enough to wait on, but we just don't have the kind of turnaround on fixes to be able to foresee a point where we can say that no package, anywhere in sarge, has a known security hole. > Does this mean people who want secure pre-compiled kernels have to > resort to unstable until the issue is fixed? Currently, unstable is in the same state as sarge wrt kernel security. -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
