Re: rc3 timeline
On Thu, Feb 24, 2005 at 03:10:19PM -0500, Joey Hess wrote:
> Ok, the important distinction to draw is security fixes that involve ABI
> changes vs those that do not. As long as the ABI remains the same, it's
> relatively easy to get fixed debs in, and to update the installer to use
> them. Not even a lot of coordination is required, we can update each
> arch independently and update the d-i udebs once we're sure the fixed
> kernel is good. When the ABI changes we have to coordinate all the
> changes to occur during a new d-i release, which is much more painful.
Ok, thanks for that distiction. I think that the best procedure
would be to contact debian-boot when we think an ABI change is coming
up. And coordinate from there. For 2.4.27 we are not there as of
today as far as I can see. Other eyes welcome.
> There's a secondary distinction between security holes that are
> exploitable remotely and local holes. As long as all the security holes
> are local (which I think all the CANs you mentioned are), they have
> little impact on the installer itself (since a local root shell in d-i
> requires all of alt-f2+enter ;-). Some remotely exploitable holes will
> need an immediate update of the installer.
My understanding is that all the fixes applied to 2.4.27 since the last
release are not remotely exploitable.
> Holes that do not effect the installer enough to require an immediate
> update can be dealt with more slowly, we can let the fixed kernel debs
> get enough testing so we know they're solid before updating the
> installer, and we can even wait until the next major release of the
> installer to update it. The only additional concern might be GPL issues
> with the module binaries being out of sync.
Ok, that sounds sensible. Could you elaborate on what you mean by GPL
issues. Are you talking about exported symbols and their GPL status?
> I imagine that we're going to have to contend with a more or less steady
> stream of kernel security issues from now until release and beyond.
> Indeed we have been for the past year or so. With the exception of ABI
> changing security holes, this has been pretty simple to deal with in
> d-i, we just wait for fixes, rebuild our kernel udebs once the fix is
> available, and put those udebs in the next major release. We do need to
> improve this process to deal more quickly with remote security holes.
> Things also become more difficult as we're making release candidate
> releases now, which involve more work to release, and which we try to
> make as final as possible. After the sarge release we will need to work
> with the security team to decide which kernel security DSAs warrant an
> update of the entire installer too.
Agreed.
> So with my thoughts on the background out of the way, here's my advice:
>
> Horms wrote:
> > The unfortunate problem is that the rc3 timeline meens if
> > a new 2.4.27 is to go in, it needs to be uploaded ASAP.
> > This in itself is a problem, because all the different arches
> > will need to update to the new kernel-source package, and
> > that typically takes a while.
> >
> > Then there is also the problem that this kernel hasn't been released -
> > most of these changes were added in the past week or so - and thus
> > hasn't been tested much. Actually, it probably hasn't even been
> > compiled on a buch of architectures.
>
> Since these are local holes with no ABI changes, whether or not they are
> fixed in the udebs released with d-i rc3 doesn't matter much. The
> installer team's main concern right now is probably that the last d-i
> release still installs a -1 ABI 2.4.27 kernel that is missing many
> earlier fixes including local root exploits and also, I think, some
> remote holes. And that upgrading to a more secure kernel after the
> install is a rather manual and touchy process due to the ABI change. I
> think correcting that ASAP outweighs the value of fixing the newer holes
> in rc3.
>
> Of course we'd still like to get the fixed kernel debs into unstable and
> testing as soon as is reasonable and safe. So I do think you should
> upload to unstable as soon as you're ready. There are however, three
> problems..
>
> 1. kernel-image-2.4.27-sparc has not made it to testing yet. I think
> kernel-latest-2.4-sparc is preventing it, since that package depends
> on things like kernel-headers-2.4.27-1-sparc64
This has an explicit dependancy on kernel-tree-2.4.27-8 (as it should),
so I guess uploading kernel-tree-2.4.27-9 would block it.
> 2. kernel-image-2.4.27-arm hasn't quite made it to testing yet either
> (should today)
> 3. the powerpc 2.4.27 kernel still isn't updated either, and is
> close to the point of not having an update included in rc3 at all.
These packages do not have such a restrictive dependancy, so they would
be fine. Though I think that is a bug in there packaging.
> Please try to avoid making any uploads to unstable that would block any
> of these, especially 1 and 2. Sven may decide to roll the new security
> fixes into the powerpc kernel, up to him I guess.
Up to him indeed. I will hold back until I get back from my trip.
I hope that Josh, Micah and others continue adding fixes to SVN as
they arrise. And certainly I will be examining issues as they come to
hand. But I would like to plan on releasing a new kernel-source-2.4.27
into unstable about 2 weeks from now.
> Any security fixes we miss for rc3 can be at least mentioned in the
> errata for that release, and should be only an apt-get upgrade away
> after rc3 is installed. We will have to look at the holes and other
> issues like GPL to decide whether it's worth updating d-i images one
> more time after rc3 with even newer kernels.
Yes, that is pretty much what I was thinking. If you want to build up
an erata for security problems, I would ask for input from Micah. That
and the changelogs that are in SVN for the various kernels.
--
Horms
Reply to: