Re: ABI-changing kernel security fixes for sarge
On Wed, Mar 23, 2005 at 07:27:20PM +0000, Matthew Wilcox wrote:
> On Wed, Mar 23, 2005 at 04:09:42PM +0100, Frank Lichtenheld wrote:
> > How big is the chance that we will have another ABI change during
> > sarge's lifetime (100%?). So it can't hurd to figure out the problems
> > with that now independently of our decision in this matter...
>
> Absolutely. It's bound to happen again. We also need to figure out
> how to do driver updates during sarge's lifetime. I suspect virtually
The easy way is to mandate that every module package in debian is maintained
in the kernel subversion repo, and we build a couple of script which autobuild
and upload from said subversion repo, which we can kick of each time we bump
an ABI. NEW processing is still problematic, but as the ftp-masters prefer to
have full control and loose time, i guess they will need to be individually
pinged by the security team.
Furthermore, not all arches have had their kernel meta packages ready for
rc3 (against because of month and a half NEW processing delay for the powerpc
case), and thus the metapackages will not be installed on new system, and
there will be no way to automatically update the kernel to the abi-fixed
packages. This is not so much a problem for powerpc as the powerpc kernels
have not yet the abi number included (which Jens considered was not worth it),
but there may be other arches where this is a problem.
> everybody has had the experience of trying to install woody on a new PC.
> Some of the problems I remember:
>
> - new PCI IDs for the eepro100 driver
> - i830 chipset not supported (also needed new X)
>
> Does d-i have an option to insert a driver disc (floppy or cdrom) or
> ability to grab a new module package from the net (suboptimal as it may
> be the network driver that's missing)?
Yes, sure.
> Either that, or we need to commit to a 6-month release goal for etch and
> future releases. Which wouldn't suck, we used to do it...
That won't solve the problem of a remote kernel exploit for sarge a month
after the release, and for the record i strongly oppose any tentative of
releasing sarge with a known remote security hole in the installer kernels.
I was about to work on a common kernel package building all kernel images in
one go, but as i was told that i am just a whiner and that neither my opinion
nor my work is appreciated, i guess someone else will have to do the work now.
Sven Luther
Reply to: