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? Issuing an advisory for 2.6.8 still seems to make sense to me, since the transition to 2.6.12 is not so obvious. Micah 1. The definition of "significant number" is up to the team or the person willing to write the DTSA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
