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
Attachment:
signature.asc
Description: Digital signature