[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kernel security upgrades



* Martin Schulze (joey@infodrom.org) [050325 17:50]:
> Andreas Barth wrote:
> > Ok, summarising this means for me:
> > 
> > If we change the abi for d-i, than a lot of work at a lot of places
> > needs to be done.  Definitly possible, but not the thing we want to do
> > for each security upgrade.  On the other side, as long as we keep the
> > old kernel around, and don't rebuild the CDs, everything is still fine.
> > 
> > The reason why we cannot keep the old kernels was - beside the fact that
> > it's not so nice if we force our users to upgrade their kernel as first
> > action - that we're overwriting the kernel source with the upgrade.
> > 
> > However, as long as the updated kernels are only available via
> > security.d.o and via {stable,testing}-proposed-updates, the overwriting
> > doesn't happen.
> > 
> > So, one idea would be to push the updated kernels into sarge only very
> > seldom (means: reserve time for exactly one more ABI transition in
> > sarge before release, rest happens only in unstable, t-p-u and/or
> > testing-security), and decide on each of the following point releases
> > whether we want to have the effort to touch all of the mentioned
> > packages, or if we keep the updated kernels only on security.d.o.

> This paragraph deals only with the current situation of pre-sarge, right?
>
> Once sarge is released, we need to expect a changed abi every month,
> even though it may not happen that often, it will happen.  It's not
> clear how to handle this...

Well, within sarge: If I understood it right, an ABI-changes on security
doesn't hurt the installer till the kernel is pushed into sarge proper.
So, pushing the kernel only if we do a point release (and perhaps even
keeping the old kernel source and images in if that's possible, so that
even business card is not broken).

Of course, this is still a can of worms - rebuilding all kernels,
rebuilding all modules, rebuilding the installer, but at least we know
what to do.

(And so to the initial question: It handles both. I would try to handle
any further kernel change exactly the way we do after release, with one
extra slot for ABI-transitions at release, and start to consider the
kernel as hard frozen as soon as possible.)



Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C



Reply to: