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.
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.
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.
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.
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
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.
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.
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.
--
see shy jo
Attachment:
signature.asc
Description: Digital signature