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

[Joey Hess]

Well, I have a few horses in this race in between testing-security,
d-i, and CUT, as well as having been a Release Assistant in the past,
and I think this proposal stinks from every perspective.

Michael Gilbert wrote:
> The biggest problem I saw during the squeeze development cycle was that
> kernel security update transitions were extremely slow due to unrelated
> RC bugs.  This was bad since it left testing users vulnerable to issues
> for much larger periods of time than stable/unstable users.  

Which proves nicely that not all RC bugs are equally RC, and that britney's
old_rc_count <= new_rc_count
is a flawed heuristic whose main virtue is that it's probably the best
a machine can do with the available information. Which is why the release
team has override files..

> Another issue was that a lot of vulnerabilities that were found in that
> time frame were actually flaws in new kernel code, so testing/unstable
> were vulnerable, but the stable kernel itself was unaffected, so it was
> a bit safer to be running the stable kernel since the code was older
> (i.e. there was more time to find and fix issues).  For example, the
> vulnerability for one of the local privilege escalations that was
> exploited in the wild was introduced in 2.6.30, so lenny wasn't
> affected, but testing/unstable were.

LWN's analysis of age of introduction of kernel security holes in 2010
doesn't seem to agree? http://lwn.net/Articles/410606/

| So, in a sense, the above-mentioned kernel hacker was correct - an
| awful lot of the vulnerabilities fixed over the last year predate the
| git era, and are thus over five years old.

At best, you seem to be grossly oversimplifying. In the immortal words
of FaceBook, "it's complicated".

> I'd like to propose a solution to these two problems: only upload known
> rock solid longterm cadence upstream supported kernels into
> testing/unstable. This will hopefully reduce the amount of transition
> delay since the longterm kernels should have fewer RC issues (after
> they've had a little time to cook of course).
> 
> There are, of course, some undesirable consequences to this plan.  One
> is that a certain subset of testing users expect the latest shiny all
> the time; but they can easily get their fix from the experimental
> kernels instead, so that isn't really a problem (I think).

I feel that unstable is heading in much too stable a direction already.
I think that Bdale mentioned this (as a possible negative feature of CUT)
at DebConf. If testing is as stale as stable, why would anyone want to
bother with CUT?

> The second issue is that testing d-i will not support the latest and
> greatest hardware and features.  I think this can be solved by
> providing two sets of d-i media for testing (one that uses the longterm
> testing kernel and one that uses newer experimental kernel).

This seems likely to increase the workload of the d-i (and CD..) team
significantly. And wouldn't it result in either an installed system that
used unstable's old kernel and so didn't work, or used experimental's
kernel and so didn't auto-upgrade to fix security holes?

Also, what are teams like the X team to do, when their packages depend
on new kernel features? How are we supposed to ever integrate support
for the new kernel distribution-wide if unstable constantly has an old
version? Should the whole distribution lag years behind the state of the
art?

> Anyway, I think this would go a long way toward improving the quality
> of security support in testing and thus reducing the common advice/meme
> that users should avoid testing if they're concerned about security.

A meme that is not founded in truth, as you can see if you compare
existing known security holes in stable and in testing at most points in
the release cycle. Perhaps the project should consider how it allows
these types of myths to stand up when their foundations are so easily
disproven?

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/cut-team/attachments/20110206/c76e7710/attachment.pgp>