[Secure-testing-team] Re: DTSA for 2.6.8 and 2.4.27

[Horms]

On Fri, Sep 09, 2005 at 08:30:39AM -0500, Micah Anderson wrote:
> Horms schrieb am Friday, den 09. September 2005:
> 
> > On Thu, Sep 08, 2005 at 09:17:25PM -0500, Micah Anderson wrote:
> > > Hi,
> > > 
> > > I think it would be a good idea to get a DTSA (Debian Testing Security
> > > Advisory) issued for 2.4.27 and 2.6.8. 
> >
> > That seems fine to me, at a glance. Though there have been some
> > aditional bugs fixed in SVN. I have added the relevant patches to all
> > trees that were effected, though as only 2.4.27 and 2.6.12 are reevant
> > to this discussion. It might be a good time to spin 2.4.27-12 and get
> > that into unstable. And linux-2.6 2.6.12-6, which was released earleier
> > this week, should be up to date.
> 
> If there are new security issues in SVN, definately spin out a new
> 2.4.27-12, but this brings up a question -- 
> 
> We haven't being doing DTSAs for every security hole that is fixed in
> unstable and naturally migrates to testing, at this point we are only doing
> them for those packages which can't enter testing on their own because they
> are blocked by something. 
> 
> The reason I was suggesting doing one for 2.4.27-11 was because there are a
> significant number of holes fixed in that release compared to previous, but
> since it migrates fine from unstable to testing, perhaps we shouldn't do a
> DTSA on it at all? Notifying testing users of security holes in all packages
> that enter testing from unstable is useful, but it may be too much of a
> burden on the team to issue advisories on them all. 
> 
> Do we want to be doing DTSAs for every new kernel version that comes out
> with security holes? If we do, we need to make a policy decision. Either we:
> 1. make it our policy to always do DTSAs for kernel security issues
> regardless if they enter testing naturally or not; or 2. make it our policy to
> do a DTSA for all packages that fix a significant number[1] of security
> issues because the significance of the threat is large enough to draw
> attention to the fix.
> 
> Thoughts?

I'm not sure, but almost every, if not every, kernel release will have
security fixes given the current rate that they are being found and
fixed - more than one a week, perhaps more than one a day.

-- 
Horms