[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kernel security upgrades

Andreas Barth wrote:
> [What changes to d-i need to be done for a security upload?]

Besides building the udebs, if the abi changes we have to update rootskel,
base-installer, and the debian-installer build system.

> The d-i changes are only finalized with the next point release - but well,
> that doesn't usually matter (except if there is remote root by a kernel
> bug), as the kernel images and source is pushed to sarge with the point
> release.
> However, there is one issue with d-i: The installer decides which kernel
> image to install in a bit arch-specific way.  On the architectures without
> a meta-package, the installer can only install the same kernel image as the
> udebs were built from.

Not quite accurate, it really tries to install the specific kernel version
that was hardcoded into it at build time. Even arches with metapackages need
this to be updates since the metapackages are not available on all media.
For sarge, the info is unfortunatly harcdoed in two places; some of it
is in rootskel and some in base-installer.

> This is actually still possible to live with, as
> the kernel images will be available till the next pointrelease, but that
> means that users get an unsecure kernel installed by default on that
> platforms, and that every point release breaks the installer CDs on that
> platforms.

A point release that introduced a new kernel abi would break old
businesscard cds, since those have the udebs that expect the old kernel,
but downloads the kernel from the archive. Unless we kept the old kernels
in the archive of course.

Something you left out is that when the kernel abi is changed, debian-cd
may also need to be changed, to exclude the kernels for the old abi (if
those are left in the archive) and to include the new kernels. Depending
on the CD build process, the inclusion of new kernels may be done
automatically (there's a script that updates the list), but exclusion of
old kernels will not, and it can fill up CDs.

> One idea how to handle this is:
> - Write scripts that make the necessary changes to the source packages, so
>   that adjusting the source packages for a security update is not more
>   effort than running one script.  The script should be able to optionally
>   make the changes for an ABI-change.

It's certianly doable..

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: