Security Supporting Debian Kernels in Sarge
We need to improve our kernel maintenance or it will be impossible to
support the Linux kernel security-wise in the future. We = Security
Team at the moment.
Some of you may have noticed that I'm struggling again (or rather
still) with kernel updates for woody. Even though this update went a
lot better than the last one, it is still not yet finished for all
In woody there are currently:
8 "native" kernel source packages (4x 2.2 and 4x 2.4)
28 kernel image/patch source packages
3 kernel image source packages including the full source
Just to give you an impression of the sheer amount of source packages
that need to be taken care of for a security update in the Linux
kernel, here's a list of the packages I know of and I am working
KV kernel-source 2.2.10
KV kernel-source 2.2.19
KV kernel-source 2.2.20
KV kernel-source 2.2.22
KV kernel-source 2.4.16
KV kernel-source 2.4.17
KV kernel-source 2.4.18
KV kernel-source 2.4.19
To make it worse the source packages went rather out of sync with
regards to security related updates. For the most important ones,
they are in sync again, but it's a pita to maintain.
It was even worse than this since several kernel packages did not even
built anymore on woody, for various reasons. For some the respective
kernel-source package was removed, for others the code wasn't
compatible with the compiler anymore. Don't ask me why.
I'm still not done with the CAN-2004-0077 (mremap) update and still
working on the CAN-2004-0109 (iso9660) update.
However, after fighting for months on an update for CAN-2004-0077 for
all architectures and all kernels, it was a lot easier to provide
updates for the CAN-2004-0109 vulnerability.
In order to be able to provide security updates for the kernel in
sarge certain rules need to apply. Otherwise we will not be able to
provide updates properly. We've already done a rather poor job in the
past, and the situation in sarge/sid is not looking promising.
1. The number of different kernel versions must not increase!
2. It is insane to expect us to support three main kernel lines
(2.2, 2.4 *and* 2.6).
3. The kernel source may only be provided by kernel-source packages
that be maintained by the security team from the beginning of the
This implies that no kernel-patch/kernel-image may contain the
full source. I've been told that this is the case already.
4. When sarge starts to go into freeze, the existing kernel packages
have to be reduced to a minimum that we have to support. It is
not acceptable to have several kernel images per architecture
when less would be sufficient to support all sub-architectures
that we want to support.
5. When sarge enter the freeze status, kernel patch/image
maintainers should investigate whether the build dependencies of
these packages are still fulfilled within sarge.
6. When sarge enters its freeze status, kernel patch/image
maintainers should re-compile these packages with the current
tools in sarge in order to find out if the packages still
compile. If they don't, they should update the patch/image
7. It would be very helpful if kernel modules maintainers would
inform me (us?) about which kernel modules packages require which
kernel versions, so that we can provide updated modules if we
need to. This is very important for pcmcia modules so that
notebook users won't lose their network connectivity with a
8. Of course, the modules packages need to have their build
dependencies fulfilled in sarge and compile as well.
9. If you fix security vulnerabilities in packages in unstable or
testing please mention the relevant CVE ID in the changelog so
the security team gets an easier chance to find out whether a
package has fixed a certain bug or not.
At the moment we have 10 kernel source packages in sarge, which is
already two more than in woody, and at lest one source package is
missing (leading to an FTBFS for at least one kernel image package).
This is too much!
kernel-source-2.2.25 testing 2.2.25-3 all source
kernel-source-2.4.19 testing 2.4.19-11 all source
kernel-source-2.4.20 testing 2.4.20-14 all source
kernel-source-2.4.21 testing 2.4.21-8 all source
kernel-source-2.4.22 testing 2.4.22-7 all source
kernel-source-2.4.24 testing 2.4.24-3 all source
kernel-source-2.4.25 testing 2.4.25-1 all source
kernel-source-2.6.3 testing 2.6.3-2 all source
kernel-source-2.6.4 testing 2.6.4-1 all source
kernel-source-2.6.5 testing 2.6.5-1 all source
There are also 31 kernel-image packages for various architectures and
versions. This is too much!
kernel-image-2.2.10-powerpc-apus testing 2.2.10-13 source
kernel-image-2.2.25-amiga testing 2.2.25-4 source
kernel-image-2.2.25-atari testing 2.2.25-4 source
kernel-image-2.2.25-bvme6000 testing 2.2.25-4 source
kernel-image-2.2.25-mac testing 2.2.25-4 source
kernel-image-2.2.25-mvme147 testing 2.2.25-4 source
kernel-image-2.2.25-mvme16x testing 2.2.25-4 source
kernel-image-2.4.17-s390 testing 2.4.17-3 source
kernel-image-2.4.19-arm testing 2.4.19-6 source
kernel-image-2.4.21-1-i386 testing 2.4.21-5 source
kernel-image-2.4.21-s390 testing 2.4.21-2 source
kernel-image-2.4.24-amiga testing 2.4.24-1 source
kernel-image-2.4.24-i386 testing 2.4.24-3 source
kernel-image-2.4.25-alpha testing 2.4.25-1 source
kernel-image-2.4.25-amiga testing 2.4.25-1 source
kernel-image-2.4.25-arm testing 2.4.25-3 source
kernel-image-2.4.25-atari testing 2.4.25-1 source
kernel-image-2.4.25-bvme6000 testing 2.4.25-1 source
kernel-image-2.4.25-hppa testing 2.4.25-2 source
kernel-image-2.4.25-i386 testing 2.4.25-1 source
kernel-image-2.4.25-ia64 testing 2.4.25-4 source
kernel-image-2.4.25-mac testing 2.4.25-1 source
kernel-image-2.4.25-mvme147 testing 2.4.25-1 source
kernel-image-2.4.25-mvme16x testing 2.4.25-1 source
kernel-image-2.6.3-alpha testing 2.6.3-2 source
kernel-image-2.6.3-i386 testing 2.6.3-2 source
kernel-image-2.6.3-ia64 testing 2.6.3-3 source
kernel-image-2.6.4-ia64 testing 2.6.4-1 source
kernel-image-sparc-2.2 testing 9 source
kernel-image-sparc-2.4 testing 35 source
kernel-image-speakup-i386 testing 2.4.24-1 source
I haven't checked whether build dependencies are still fulfilled but
looking at kernel-image-2.2.10-powerpc-apus and
kernel-image-2.4.17-s390 I have some doubts they are.
There are also 62 kernel-patch packages of which at least the
following 17 seem to produce kernel-image packages:
kernel-patch-2.4.19-mips testing 2.4.19-0.020911.9 source
kernel-patch-2.4.19-s390 testing 0.0.20021125-1 source
kernel-patch-2.4.20-apus testing 2.4.20-1 source
kernel-patch-2.4.20-hppa testing pa35.3 source
kernel-patch-2.4.21-hppa testing pa7.3 source
kernel-patch-2.4.21-s390 testing 188.8.131.52-4 source
kernel-patch-2.4.22-mips testing 2.4.22-0.030928.5 source
kernel-patch-2.4.22-powerpc testing 2.4.22-13 source
kernel-patch-2.4.25-apus testing 2.4.25-2 source
kernel-patch-2.4.25-arm testing 20040316 source
kernel-patch-2.4.25-hppa testing 2.4.25-pa1 source
kernel-patch-2.4.25-ia64 testing 2.4.25-2 source
kernel-patch-2.4.25-m68k testing 2.4.25-1 source
kernel-patch-2.4.25-powerpc testing 2.4.25-4 source
kernel-patch-2.4.25-s390 testing 2.4.25-1 source
kernel-patch-2.6.3-ia64 testing 2.6.3-2 source
kernel-patch-2.6.4-ia64 testing 2.6.4-1 source
This makes it 10 kernel source packages, with at least two missing and
48 kernel image/patch packages that need to be taken care of in case
of a security update.
Expecting the security team to support these is just TOTALLY INSANE.
If you want us to support the Linux kernel once sarge is released,
please help us keep the number of different kernels small and
buildable at least. Keeping them maintainable would be even better.
To quote a member of the security team:
Joey: in sarge we have 11 kernel-source packages
We will release with 11 kernel-source packages over my dead, decaying body.
-- Matt Zimmerman
 CVE IDs are unique identifiers for vulnerabilities in software.
<http://www.debian.org/security/cve-compatibility> You can search
for an id on <http://cve.mitre.org/cve/> on your own. You can
also contact the security team if they know of an idea for a
certain bug as well. We may have seen it somewhere already.
Given enough thrust pigs will fly, but it's not necessarily a good idea.