Deleting an alpha iso for the safety of users hardware

[Steve Langasek]

Hi Vincenzo,

On Fri, Oct 03, 2008 at 01:59:55AM +0200, Vincenzo Ciancia wrote:
> > This is not "bureaucratic".  A working milestone image can't be
> > produced at
> > random, it takes approximately a week to prepare and validate a set of
> > images and we can only muster one of these once every two weeks (at
> > best).
> > Doing a new alpha release right would have meant deferring the beta;
> > doing
> > it wrong is no better than just deleting the images, since there's no
> > guarantee they'll work.

> I didn't know this and would like a better explanation to the benefit of
> everybody who is wondering why.

> So: suppose I take the alpha iso and mount it, I am 80% confident that I
> can blacklist e1000 easily by hacking some of the contained files. This
> would take a couple of hours, and leave the alpha exactly as is, without
> changing any package except for blacklisting e1000 - and I suppose
> md5sums and eventual signatures of the iso. This is a quick and dirty
> fix, and I am sure you may think of many better methods, so why whould
> this take a week? What's wrong with the above?

The alpha-6 release included 30 ISOs, including 6 DVDs.  There are no
provisions for on-the-fly ISO editing in the Canonical data center (nor, for
security reasons, ought there be); some of the places where blacklisting
would need to happen are inside of official .deb packages, not just on the
CD filesystem; and the attempts by the kernel team to blacklist this module
were unsuccessful as shown in the bug log, so anyone attempting to implement
such a blacklist in the CDs would have to contend with the same sort of
complexity.

This is clearly not a matter of a couple of hours.

> The urgency of the problem (reversibility of the damage was not known at
> the times, and notice there is not a program yet to do that) suggests to
> me and probably many other people that the isos should have been made
> unavailable immediately after discovering the problem. I think I have
> seen such things as making downloads temporarily unavailable, and
> uploading a quick-patched release (with such fixes as disabling a driver
> as you did in the archvies) in many other releases of software.

Something to keep in mind here is that the overall chances of encountering
this bug are quite low.  Loading the driver or using the network does not on
its own corrupt the firmware; you have to have the driver loaded, and then
trigger a separate kernel bug that scribbles over the memory, and only a
certain subset of PCI IDs are vulnerable in the first place.  The bug was
present in the intrepid kernels for at least three weeks, but only a handful
of users reported having the problem - and none reported having their nvram
corrupted by the Ubuntu alphas /after/ announcements of the issue were
posted.

Actually, one user did report corruption afterwards - by installing the
intrepid kernel on a Debian etch system.  That's not exactly something that
would have been prevented by pulling the alphas.

So there's not really any evidence that leaving the alpha images up was a
reckless decision.  From what I see, the announcements and warnings that
were posted had the intended, and expected, effect.

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