Re: security in testing
On Thu, May 15, 2003 at 01:24:08AM +0200, Adam Borowski wrote:
> What about having a dummy package "testing-security", consisting of
> nothing but a huge list of versioned conflicts (and perhaps a few hints in
> /usr/share/doc/ about how to setup a mixed stable/testing or
> testing/unstable apt source list)?
This is what Joey Hess just suggested, and the harden packages are an
example of this approach.
> As the biggest concern seems to be the fact that maintaining four
> distributions at a moment is too much work, it might be a good idea to
> make it take a single command to mark a package as having a security hole.
> The idea is to have a script like:
> testingbug hole 1.2.3-45
> runnable by the security team, the package maintainer (or perhaps just any
> random DD), which would mark version 1.2.3-45 of the package 'hole' as bad
I already keep records of much of this information insofar as I am able, in
order to speed the process of review when the next release comes about (to
ensure that known holes are fixed in the upcoming release). If someone is
really and truly going to do this, I have no problem in arranging for a feed
of some sort to send them what information I can. For the most part, the
volunteer could get by just by watching advisories and the BTS.
However, the approach you describe is too simplistic; there is no indication
as to whether the problem is fixed in stable or unstable. Packages migrate
from unstable to testing on a daily basis, and so that version of the
package could be gone before the conflicting package even makes it into
testing. In order to work, the package would need to have the version
number of the fixed package, and conflict with all versions less than that.
Otherwise, it will often be inaccurate.
--
- mdz
Reply to: