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

[Anthony Towns]

Not cc'ed outside of the cut-team list.

On Mon, Feb 7, 2011 at 11:58, Joey Hess <joeyh at debian.org> wrote:
> 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.

I don't mind stinky proposals personally, as long as they don't get in
my way. One of the difficulties I think this subproject's having is
that "CUT" is being used to describe three or four fairly incompatible
aims. I think it'd probably be helpful if we switched to different
terms; that way people who're interested in, say,
tracking-upstream-more-closely and think "CUT" is the way to make that
happen, don't end up talking at cross-purposes with the people who
want to replace-stable-with-testing-for-more-use-cases and think "CUT"
is the way to achieve that.

I'm not really sure what the ideas people are currently bouncing
around are (and no one seems to be updating cut.debian.net with them
either...), so here's my guesses:

  1) testing point releases: installable, regular releases of testing,
at somewhere between once every 3-6 months. This is what's described
at  http://cut.debian.net/snapshots/implementation_plan/

  2) testing snapshots: this is (I think) what Michael's doing

  3) rolling suite: this is  (I think) what Raphael and Lucas are
interested in -- getting a new "testing" like suite that more closely
tracks unstable/upstream

  4) destabilise unstable: this is (I think) what Bdale and others are
interested in -- getting unstable to track upstream more closely and
not be as constrained by release related issues

> 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.

(If that's really one of the biggest problems during squeeze's
development, that's pretty cool: it's easily worked around, and pretty
self-contained)

>> I'd like to propose a solution to these two problems: only upload known
>> rock solid longterm cadence upstream supported kernels into
>> testing/unstable.

Not that that directly opposes the "destabilise unstable" goal above.
Personally, I'd rather have the latest versions of all the upstream
maintained kernel versions available in testing/unstable; but I
understand that's not terribly convenient with the current packaging
structure.

> 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?

IMO, the most convincing way to change that perception would be to
have an automatic ongoing tracker of the currently known security bugs
in oldstable, stable, testing and unstable.

As I see it, there'd be three possible outcomes: the numbers are sound
and indicate testing is already better than stable/oldstable from a
security POV; they indicate stable's better than testing and we get a
better idea of what to do to fix it; or the numbers aren't sound and
the incorrect conclusions motivate someone to flame us with details of
exactly what's wrong with them. Any of those outcomes sound like a win
to me. :) I've not been able to grok how CVE's and so on are assigned
well enough to count security bugs so far though, so I haven't done
this myself. Hints appreciated.

(And, obviously, there's a potential scaling problem in the sense that
a remote root in the default kernel is probably worse than five extra
packages with bad tempfile handling in non-suid executables, but hey,
it'd be a start. And what's the worst that could happen? We get a
better heuristic for evaluating RC bugs that we can incorporate into
britney?)

Cheers,
aj

-- 
Anthony Towns <aj at erisian.com.au>