Re: which kernel version for etch
* Frederik Schueler (fs@debian.org) [060716 16:15]:
> Due to various problems, 2.6.16 has not made it into testing yet,
> sadly postponing the BETA3 release of D-I.
> The two local root vulnerabilities have delayed this even more now,
> but latest Linux-2.6.16 was uploaded with urgency=high including all
> security fixes and should enter testing ASAP.
Ok. I will try to put something along that into the next release update.
I hope this is ok for you.
> > The plan also
> > included a small window around October 15th to allow an ABI bump / a new
> > kernel version into etch - I hope this is still ok for all involved.
>
> Looking at the 2.6.16.x ABI change history and considering our open
> topics with the 2.6.17 package we want to complete before kernel freeze,
> there will probably be a few more ABI bumps before the package is finally
> ready.
> We probably will need some flexibility here, especially in the light of
> the last two security issues. But this should be discussed when at the
> appropriate time.
>
> So far, we can only say: one ABI bump will probably not be enough.
Hm. Frans, how much effort is an ABI bump on the d-i side?
Actually, there will be a time when the kernel is frozen hard,
independend of how late we try to have it. There is no way around that,
except by not releasing at all.
The only "way out" that I see is that from the frozen hard time on,
there needs to be some security support for the kernel, so that in case
there are issues, we can release a newer kernel via security.debian.org.
Of course, there is nothing that makes it impossible to put updated
kernel images to testing-proposed-updates - just that they're not
installed by default. This might be ok for testing the issues, but I'm
not the final jugde on that.
> I would like to point out the we will not allow a release of Etch with a
> vulnerable kernel, as it happened with Sarge, and from discussions on
> IRC I am sure this is a consensus. Updating and building the kernel
> images, udebs and the installer currently takes approximately one week
> round trip time.
When do you think is the latest chance for us to say "stop, we need to
exchange the kernel"? Before the final d-i build, before the last
britney run, before the symlink is moved, before the packages files are
generated, before the mirrors are pushed, before the CDs are built?
There will be a "sorry, it is too late"-date - we only can change when
it is. Perhaps we should really try to write down when this point in
time is going to be, that might make our decisions easier later on.
Actually, I think it's way more important that we make sure we have
infrastructure ready on each and every day to update the kernel, than to
try to delay this point in time for a few hours or days. Because we will
need that not only before release, but also after release, and if I look
at the amount of kernel root exploits, we will need it quite fast.
AFAICS the round trip time is more than a week, because the resulting
d-i images need some heavy testing before we declare them stable. Even
if it is only one week, with more than one security issue per week
(which happened quite often for the current kernels series), we cannot
release at all. Is that really what we want? Or shouldn't we really
rather be fast to give the people with net access access to updated
kernels? (And please consider that right now, we still have an installer
with buggy kernel images for sarge, and people are required to update
their kernels via security.d.o - for more than one year now. Is the
difference of a few days before release really so bad?)
Also, what I considered quite problematic in sarge was that we had a
long time span of uncertainity, where we neither decided to exchange the
kernel nor decided to rather not, and then did it when it was even
later, which just makes the cost for all parties higher. That is
something I really want to avoid this time. I hope we can agree on that.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
Reply to: