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

[Michael Gilbert]

On Sat, 19 Feb 2011 22:28:17 +0100 Bastian Blank wrote:

> On Sat, Feb 19, 2011 at 03:55:03PM -0500, Michael Gilbert 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
> 
> Actually you did not yet proof this. Please do it.

I did verify it for the timeframe of the LWN study.  Actually, there is
no such thing as a proof ;  I suppose I could do a more thorough study
using the detailed kernel-sec data over the entire squeeze development
cycle...but that may take a while since I don't have much free time
any more.

> >   Criteria: fewer vulnerabilities in squeeze than wheezy during wheezy testing cycle
> >   Evidence: to be collected # vulnerabilities in squeeze and wheezy
> >   Conclusion: to be determined
> > 
> > Hypothesis 2: using an older kernel version makes less work to provide CUT
> > 
> >   Criteria: how often CUT target release date is met
> >   Evidence: to be collected monthly release date by retaining 2.6.32 and monthly
> >             for standard unstable->testing transitions
> >             (note: requires a 2.6.32-only period for reference)
> >   Conclusion: to be determined
> 
> Hypothesis 3: Testing users wants old software
> 
>   Criteria: to be determined
>   Evidence: easy
>   Conclusion: sorry, no chance

Users have a variety of desires.  It's the developers job to make the
best overall decision regardless of users' immediate demands. The
release team fights with this all the time during the freeze (users
want new software, but the risk of breakage outweighs their immediate
wants).

> > 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?
> 
> You can run you little experiment. For blocking packages please persuade
> the release team as responsible entity within Debian.

Isn't it the kernel team that I need to convince? That's what this
discussion is all about.

Thanks,
Mike