On Thursday, May 15, 2003, at 12:42 AM, Matt Zimmerman wrote: <snip>
The idea being discussed, as I understand it, is to have fewer securityvulnerabilities in 'testing'. The only sane way to accomplish this is tofix the bugs. There has been a disproportionate amount of strategizing around this simple idea.
The problem, as I see it, is that it's not always a case of just fixing the security bugs. The version of samba in unstable has the security problems fixed, but there's all sorts of other issues holding it up from going into testing.
You could hold to the argument, and claim that those bugs also need to be fixed in order to remove the security vulnerability from testing. I don't think this is appropriate, however, since it means the vulnerability may be present for far longer than it needs to be.
Alternatively you could argue that someone needs to prepare special security updates for testing. This may be ideal - a fixed package could be put into testing and all would be well. But as you've pointed out, nobody seems to be volunteering to organise this - so it probably wont start happening any time soon. And there's probably a strong argument that it's overkill and that effort would be better spent on fixing all the weird bugs that are stopping an update moving from unstable to testing in the first place.
Hence my suggested middle road where we simply remove/replace the packages with security vulnerabilities. Then testing will have no known vulnerabilities (or at least none the user wasn't explicitly warned about). It may also mean that a user has to go out of their way to get a package, since it isn't in testing any more - but since their running testing I have little sympathy for that. People running testing should be prepared to put in a bit more effort to achieve what they want - they just shouldn't be expected to be omniscient about all the security problems as they become known.
-- Chris
Attachment:
PGP.sig
Description: This is a digitally signed message part