[Secure-testing-team] [RFC] in-d-i upgrades

[Joey Hess]

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