Re: Maintaining kernel source in sarge
Martin Schulze <joey@infodrom.org> wrote:
>
> Manoj emphasized[1] that using one single kernel source package per
> kernel version and maintaining several patch packages for each
> architecture which finally build our kernel-image-$version packages is
> possible.
It seems that there is some confusion here as to what the term kernel source
package means.
I believe Martin is referring to Debian source packages, i.e., the things
that you get via apt-get source and make binary packages out of. It
would be advantageous for security fixes if there were only one such
package so that multiple kernel-image packages can be built from it.
Manoj on the hand (correct me if I'm wrong) is referring to the source
code of the Linux kernel which is an entirely different beast. There
is no doubt that we can get away with just one kernel-source binary
package per version. Indeed, this is already the case bar two
architectures, ia64 and hppa.
The goal that Martin is trying to achieve is indeed a noble one.
Unfortunately I personally believe that it is not realistic. It will
not become achievable until one of the following happens:
1. We reduce the number of architectures that we support.
2. The upstream kernel starts supporting multiple architectures by default.
3. We do not release kernel packages until all architectures are up-to-date.
This could take up to a year in some cases and would require a lot of
man-power.
1 is politically infeasible. 2 is out of our reach. 3 can be done but
in my opinion it is undesirable as the changes that cause delays in
architectures from being up-to-date are probably going to be the ones
that make back-porting security fixes difficult or slow. And yes we
will have to back-port them if we went down that route.
So unless someone can come up with a solution to this problem,
we will have to live with multiple Debian source packages for now.
This does make security fixes more difficult than it would be otherwise,
however, I do not think it is unsurmountable given enough cooperation
from the people involved.
Here is my rough idea as to how it can work:
1. The architectures should be treated as independent packages.
We should not be shy of releasing DSAs for some architectures before
others. Since we cannot assume that all architectures are at the same
version, some will inevitably take longer to fix due to the back-porting
involved.
When a security alert is raised, the Security Team can either start
building kernel images themselves or notify the kernel maintainers to
do it. Then multiple DSAs can be released as the images are built
and uploaded.
2. We should be more liberal about adding new kernels to the stable
archive and getting rid of old ones.
The main advantage to this is in fact security. It is routine for small
security fixes to enter a stable kernel unannounced. For instance,
between 2.4.18 and 2.4.19, dozens of unannounced small security which only
affect specific drivers were fixed. It also minimises any back-porting
that has to be done when a security alert is raised.
The disadvantage is of course the potential to break existing systems.
However, I believe this can be minimised through careful management and
thorough testing. It is also mitigated by the fact that we allow multiple
kernels to be installed simultaneously so it is easy to roll back.
In fact, due to the use of modules, it is often impossible to make
security fixes which are module ABI compatible with previous kernels.
For example, the last two security holes (ptrace and net hash) both
changed the modules ABI.
3. All kernel-image maintainers should make sure that their packages
can be rebuilt on a system other than their own. This needs to be
stressed since these packages aren't checked by the autobuilders so we
need to be extra careful.
Let me make it a bit more concrete as to what we can do about woody
right now.
Problem: Too many kernel-source packages.
This is caused in part by gratuitous kernel-patch dependencies.
Kernel-patch packages should *never* depend on a kernel-source
package since the user can always use a kernel tar ball.
Solution: Remove offending kernel-patch packages and kernel-source packages.
Users of those kernel-source packages should be encouraged to upgrade to
a later version. I'd recommend that we keep 2.4.18 and inject 2.4.19/2.4.20
as soon as possible. All architectures have kernel images in either
stable or proposed-updates that is at least 2.4.18 or higher.
For 2.2 I suggest that we move to 2.2.25 ASAP and move the one remaining
architecture that only work on 2.2 (m68k) to it.
Problem: Too many kernel-image souce packages.
We will have to live with this one.
Solution: None. However, if we treat each architecture indenpendently,
the task for releasing security fixes becomes more manageble. This
is also easier if we regularly update the kernel-image packages in stable.
Problem: Binary module packages.
This is actually not too bad for woody as we seem to have only one of them
for 2.4 (alsa compiled against 2.4.16). We have four module packages in
sid at the moment and I believe they're only compiled on i386.
Some have suggested that they should be built from the kernel-image
source packages. This does indeed have merit as it makes it easier
to make binary module packages. However, it does have the downside that
a change in any module source package will cause the entire
kernel-image to be rebuilt or wait for the next kernel-image bulid which
could be months away. It also means that if the module source
develops a build problem, the entire kernel-image may be delayed.
Solution: Remove alsa modules package from woody as we never had a
2.4.18 upload to woody. For future Debian releases, do not delay the
release of kernel-image DSAs while waiting for module packages.
This is not as bad is it looks as if properly managed. Kernel images
should either be ABI compatible with existing modules, or it is possible
to have it installed simultaneously with an old kernel image when the
ABI changes.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Reply to: