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

Re: [D-I] Preparing for update in stable



On Sat, Apr 29, 2006 at 12:36:10PM +0200, Frans Pop wrote:

> > Or, a totally different idea: Why do we (technically) need to 
> > rebuild the installer at all? Could we try to avoid that need in
> > future?

> The main reason (AIUI) we want to have a new installer with new kernel 
> udebs is that the kernel udebs are directly derived from the kernel 
> images, so if the kernel images disappear from stable, the kernel udebs 
> derived from it should also disappear and be replaced with new kernel 
> udebs derived from the current kernel images. Otherwise Debian would no 
> longer be shipping the full source for the installer.

FWIW, in the sarge r0 case, the ftpmasters created a special dak suite to
store the kernels that needed to be kept around, so that we could include
one round of security fixes already without having to rebuild the udebs and
kernel images:

$ madison -s sarge-r0 -a i386 -r .
kernel-image-2.4.27-2-386 |   2.4.27-8 |      sarge-r0 | i386
kernel-image-2.4.27-2-586tsc |   2.4.27-8 |      sarge-r0 | i386
kernel-image-2.4.27-2-686 |   2.4.27-8 |      sarge-r0 | i386
kernel-image-2.4.27-2-686-smp |   2.4.27-8 |      sarge-r0 | i386
kernel-image-2.4.27-2-k6 |   2.4.27-8 |      sarge-r0 | i386
kernel-image-2.4.27-2-k7 |   2.4.27-8 |      sarge-r0 | i386
kernel-image-2.4.27-2-k7-smp |   2.4.27-8 |      sarge-r0 | i386
kernel-image-2.6.8-2-386 |   2.6.8-13 |      sarge-r0 | i386
kernel-image-2.6.8-2-686 |   2.6.8-13 |      sarge-r0 | i386
kernel-image-2.6.8-2-686-smp |   2.6.8-13 |      sarge-r0 | i386
kernel-image-2.6.8-2-k7 |   2.6.8-13 |      sarge-r0 | i386
kernel-image-2.6.8-2-k7-smp |   2.6.8-13 |      sarge-r0 | i386

So doing the same again wouldn't be any *worse* than what we did for r0. 
But it would also be nice to do better, and get our kernel images and
installer in sync for a point release.

> The second reason is security. Although the risk of an attack during 
> installation is relatively small, it can't be completely excluded.

It was my understanding that the fix for a remote security bug (DoS
only?) was deferred beyond r0 because it was ABI-breaking.  So that does
indeed seem worthwhile to get taken care of for the installer.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature


Reply to: