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[1], 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
affected.
security teams:
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 [1] should
be avoided.
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.
release team:
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
security fixes.
(By the way, it will be possible to disable the upgrades, eg by booting
d-i with "pkgsel/upgrade=none".)
--
see shy jo
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479431#69
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20080628/439ccfdc/attachment.pgp