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

Michael Gilbert michael.s.gilbert at gmail.com
Sun Feb 20 21:29:09 UTC 2011


On Sun, 20 Feb 2011 08:24:32 +0100 Lucas Nussbaum wrote:

> On 19/02/11 at 17:40 -0500, Michael Gilbert wrote:
> > On Sat, 19 Feb 2011 21:39:03 +0000 Ben Hutchings wrote:
> > > > Hypothesis 1: using an older kernel in testing results in fewer vulnerabilities
> > > > 
> > > >   Criteria: fewer vulnerabilities in lenny than squeeze during squeeze testing cycle
> > > >   Evidence: lenny's kernel was vulnerable to 67% of the vulnerabilities that squeeze
> > > >   Conclusion: hypothesis verified
> > > >   
> > > >   Criteria: fewer vulnerabilities in squeeze than wheezy during wheezy testing cycle
> > > >   Evidence: to be collected # vulnerabilities in squeeze and wheezy
> > > >   Conclusion: to be determined
> > > 
> > > This experiment does not require that the propagation of kernel packages
> > > into testing is changed.
> > 
> > OK, revised hypothesis 1: using 2.6.32 in wheezy for the first year of its development
> >                           will result in fewer vulnerabilities
> > 
> >   Criteria: fewer vulnerabilities in wheezy/2.6.32 vs unstable kernel over 1 year period
> >   Evidence: to be collected # vulnerabilities affecting 2.6.32 and kernel in
> >             unstable at the same time
> >   Conclusion: to be determined
> > 
> > > > I can't imagine anyone else being put through such a arduous process
> > > > to try an experiment for a couple months.  Why does it have to be so
> > > > difficult?
> > > 
> > > Because this experiment would involve many thousands of users, and you
> > > have to convince other developers that the benefit to these users may be
> > > worth the cost.
> > 
> > OK, are you sufficiently convinced to give me a chance at this
> > experiment, at least for a couple months???
> 
> I don't understand why you think that testing or CUT users want an "old"
> kernel, but want to run recent software for everything else on their
> system.

I've already answered that in another mail.  But basically the answer
is a transition to unstable for users that *don't want* the
older/stabler kernel. Of course that does require users to change their
ways, but that's not so bad.  In fact it may be good to have more users
running unstable, finding bugs, and submitting reports.

> Also, you need to see the downsides of this proposed experiment. By not
> upgrading the kernel in testing, you will limit the amount of testing
> that the new kernel will receive. That could, in turn, cause more bugs
> to be found late in the wheezy release process, making it harder to
> reach a newer stable kernel.
> Or are you suggesting that we stay with 2.6.32 forever? ;)

Of course not ;)  I actually think there are a lot of people using
unstable, and those are really the best users to find bugs in the
kernel anyway (since presumably they actually know what they are
doing).

I suppose that would be an alternative hypothesis: keeping 2.6.32 in
testing for too long will lead to a lower quality final wheezy kernel.

That's more of a subjective/qualitative issue, and I don't really know
how to define criteria to quantify it.  But like I said, in my opinion
unstable users are sufficient to work out the bugs.

Best wishes,
Mike



More information about the cut-team mailing list