[Secure-testing-team] [cut-team] For discussion: security support strategy for the wheezy kernel
Michael Gilbert
michael.s.gilbert at gmail.com
Sat Feb 19 20:25:29 UTC 2011
On Sat, 19 Feb 2011 14:59:27 -0500 Michael Gilbert wrote:
> On Sat, 19 Feb 2011 19:32:08 +0000 Ben Hutchings wrote:
>
> > On Sat, 2011-02-19 at 14:04 -0500, Michael Gilbert wrote:
> > > On Sat, 19 Feb 2011 18:48:40 +0000 Ben Hutchings wrote:
> > >
> > > > On Sat, 2011-02-19 at 13:12 -0500, Michael Gilbert wrote:
> > [...]
> > > > > 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)
> > > >
> > > > Huh? I don't see any source for this figure.
> > >
> > > http://lists.alioth.debian.org/pipermail/cut-team/2011-February/000193.html
> > > http://lists.alioth.debian.org/pipermail/cut-team/2011-February/000194.html
> >
> > I read those and I can't see any source for comparison between 2.6.32
> > and 2.6.37. In fact you say that 'squeeze (2.6.32) was vulnerable to
> > 98% (51 out of 52)' which implies only 2% fewer vulnerabilities.
>
> I suppose the way I said that is confusing. That research was from
> past results, and my latest statement is a projection based on the
> past. In other words, if lenny was vulnerable to 67% of the issues that
> squeeze was, I'm projecting that it will be similar for squeeze: it
> will be vulnerable to about 67% of the issues that wheezy will;
> although that could be +-10%, +-20%, who knows since events have yet
> to happen.
I still think I've written this confusingly. Let me try one more time.
Over squeeze's testing period, the stable kernel (2.6.26) was
vulnerable to roughly 67% of the issues that the testing kernels
(2.6.28-32) were vulnerable to. Hence projecting for the future,
over wheezy's testing period, the stable kernel (2.6.32) will be
vulnerable to roughly 67% (+- some uncertainty value) of the issues
that the testing kernels (2.6.37-4x) will be vulnerable to.
Best wishes,
Mike
More information about the Secure-testing-team
mailing list