[Secure-testing-team] [RFC] in-d-i upgrades
joeyh at debian.org
Sat Jun 28 20:40:55 UTC 2008
I've been working on a fix for bug #479431, and before I apply it to
d-i, I want to make you aware of it, since it can have repercussions to
DSAs and release management.
To summarize the problem for non-d-i developers:
If a user is installing from a CD or mirror, debootstrap is used to
install packages from that CD/mirror, and d-i also installs a kernel
and some other packages, before security.debian.org is configured as
an apt source. So, many installations do not get all security updates
applied, until the user manually upgrades the system later. This is a
potentially crucial window to close.
While it might be nice for debootstrap to pull in security fixes from
security.debian.org from the beginning, this is not possible given its
current design, and some of its constraints such as needing to be
implemented portably and run in the limited d-i environment also make
it hard to it have this capability.
Rather than change debootstrap, I modified d-i to upgrade packages that
debootstrap has installed, once security sources are available. The
problem with doing such an upgrade inside d-i, though, is that it
exposes installations to the entire class of problems that can occur
during an upgrade, and breaks the installation process if the upgrade
fails for some reason.
So if we make this change to d-i, the security and release teams can be
If you're making a D[T]SA for a package that is installed by
debootstrap, or of the kernel, or of (some) of the other packages listed
at <http://release.debian.org/britney/noremove.d/> (d-i* files), you
will need to keep in mind that d-i will upgrade it to the fixed version
inside the d-i environment, and that all the issues I list in  should
Notable amoung these are avoiding non-debconf prompts, which can
hang/confuse d-i, and trying to avoid prompts that don't make sense in d-i,
such as the kernel's warning about upgrading a running kernel version.
I guess the main impact will be that, after a d-i release candidate is
available, any updates to base or the d-i noremove.d packages have the
potential to cause any of the abovementioned upgrade problems, and if
that happens, someone will have to notice and fix it.
I don't like that this change adds a new class of problems to watch out
for, and tends to make things a bit more fragile. But having new
installs boot up to an insecure kernel, running insecure daemons, when
fixes are available on security.debian.org, is just too large a risk to
leave in the installer in a world where windows machines are known to be
hacked into in the period between their first boot and application of
(By the way, it will be possible to disable the upgrades, eg by booting
d-i with "pkgsel/upgrade=none".)
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20080628/439ccfdc/attachment.pgp
More information about the Secure-testing-team