Re: kernel/d-i/security/release meeting at DebConf6
On Wed, May 24, 2006 at 10:31:08AM +0200, Andreas Barth wrote:
> * Sven Luther (sven.luther@wanadoo.fr) [060524 06:33]:
> > Well, as a proof of my claims, the sarge d-i released with a known remote
> > security hole, and there has been no (or maybe 1 by now ?) d-i update since
> > then.
>
> You mean, a remote root exploitable hole? If so, which bug, and why
> wasn't that information sent to debian-release? Or is it "just" a remote
> DoS-issue?
Ah, i don't remember the details exactly. It was indeed a remote security
issue, but i don't remember if it was an exploit or a DoS kind of thingy. The
issue was well known by the release managers of the time, and the decision to
ship with it was taken in conjunction between the release managers and the d-i
team. The rationale was that d-i was going to install a newer kernel anyway,
and the system would be vulnerable only during the time of the install, which
still seemed unacceptable to me back then, altough a bit less so if it was
just a DoS, but my understanding of back then was that it was a hole. I may
have been wrong though.
The issue is widely documented on the lists, debian-boot, probably
debian-kernel, and maybe even debian-release in april 2005, as well as the
subsequent kernel changelog entry of the sarge kernel.
The problem back then was that the poor kernel state meant a 30+ days upgrade
path, which was partly caused by the kernel, but partly by the d-i folk too.
> > And again this time, d-i freeze is scheduled
> > first week of august, and this means we need to have the kernels frozen a week
> > or so before that. This is something like 5 month before the actual release
> > date of etch.
>
> You are ignoring that we have scheduled a time to update the kernel
> again before release of etch.
Ah, nice. But would this include an abi-changing kernel upgrade ? I fear not,
given the trouble of abi changes for security upgrades. In any case, it
doesn't include an upstream kernel version bump in the planes i have read,
right ?
We should be able to rebuild all those packages on all release arches within a
couple of days, a week at most, if we do it right. This doesn't seem to be
worth the effort to many in this discussion though, who prefer the status-quo.
Friendly,
Sven Luther
Reply to: