[cut-team] For discussion: security support strategy for the wheezy kernel

[Michael Gilbert]

On Sat, 19 Feb 2011 14:09:50 +0100 Raphael Hertzog wrote:

> On Fri, 18 Feb 2011, Michael Gilbert wrote:
> > This will also help to provide a bit more stability for CUT [0].  Over
> > a 1.5-year period (the non-freeze timeframe) roughly 6 new upstream
> > kernels will be released, and each new kernel comes along with a high
> > probability of introducing breakage.  I'm trying to provide CUT
> > releases once a month, so every 3 months I will be looking at a likely
> > broken CUT release (or 25% of the time).  However, if there is just one
> > kernel transition in testing development cycle, then there is only 1
> > likely broken period (or 4% of the time).
> 
> The kernel is not the sole component that can introduce breakage. So it
> seems ridiculous to do such statistics based on the kernel only.

Hi Raphael, I completely concur that there are indeed other important
components like grub and xorg where breakage would be a showstopper.
However, I don't think the consequences would be quite so substantial.
There is just so much intimately dependent on the kernel that breakage
there has a very wide area of effect; whereas grub or xorg breakage is
somewhat contained.  This is why I'm only significantly concerned about
the kernel.  Anyway, I agree that there will be breakage, but I don't
want CUT to be mostly about constantly resolving the same repetitive
kernel breakage.

Also, this solution isn't just about CUT stability.  As I've been
describing, it is about killing about 2 birds with one stone:

1. Make testing always installable by retaining a stable/well-tested
kernel and associated d-i infrastructure
2. Improve testing security by reducing the amount of vulnerabilities
existent in older kernels (roughly 67% fewer in 2.6.32 vs 2.6.37 as
described previously)

In fact these are two of the three known problems in testing mentioned
in your LWN article [0].  And the only consequence is that testing users
don't get the latest kernel bling.  However, that is offset by the
availability of 2.6.37 and associated infrastructure in unstable.  So
there really are no downsides that can't be worked around with a little
education/effort on the part of the user.

> And like Lucas said, CUT users want recent software and that includes the
> kernel

I don't think it is appropriate to project a singular perspective onto
all users.  Ultimately our goal is to perform a balancing act between
freshness and stability.  In the past the primary focus has been on
freshness in testing, but I think there is room to swing the pendulum a
bit more toward stability.  It's really a requirement if we're ever
going to be able to achieve something a testing that's "constantly
usable". Also, users needing bleeding-edge freshness can always take
the plunge into unstable.

> (which is also important for new hardware support).

This seems to be a meme that continues to persist without much in the
way of evidence.  It certainly may have been true in the past, but I
think things have changed for the better with the advent of stable
upstream support (i.e. support for new hardware is backported to the
stable kernels).

Also, I've read about 10 reviews of squeeze, and none of them have
indicated any problems with hardware support (except for missing
support for non-free firmware) even though that uses a kernel initially
released almost a year and a half ago.  In fact, I've only ever had one
piece of hardware (a wireless card) that was unsupported by Debian, and
that was when sarge was still in testing, and all that was needed was
to enter the device id into the discover list.  It wasn't even a kernel
issue.

Ultimately I don't see why the newest blingy kernel is a necessity in
testing.

Best wishes,
Mike

[0] http://lwn.net/Articles/406301/