[Secure-testing-team] Re: Removing insecure packages from etch

Goswin von Brederlow brederlo at informatik.uni-tuebingen.de
Wed Aug 16 03:07:31 UTC 2006


dann frazier <dannf at dannf.org> writes:

> On Tue, Aug 15, 2006 at 11:58:04PM +0200, Moritz Muehlenhoff wrote:
>> I'm trying to follow debian-devel and giving advice where possible.
>> Unfortunately most people just don't care; e.g. I strongly recommended
>> to dump mantis completely. Still someone NMUed it for some non-DD who'll
>> most definitely in half a year lose interest like the two previous
>> maintainers and leave that junk in the archive with the Security Team
>> needing to support it for two more years. A package with only 35 installed
>> popcon users and _20_ vulnerabilities since January 2005. Or elog, a
>> _horribly_ insecure electronic web logbook written in C, which had every
>> basic security flaw you could ever imagine. The DSA fixed seven CVEs,
>> at the time of DSA it had six voting popcon users...
>> 
>> It's packages like these which kill the fun out of preparing security
>> updates for Debian.
>
> What about filing bugs against ftp.debian.org requesting the removal
> of these packages, and asking the release managers to block the etch
> release on these bugs?
>
> Or, perhaps file a grave bug against each package stating that it
> cannot be security supported and ask the release team to drop it
> from etch.
>
> Probably best to just ask the release team (cc'd) for their preferred
> approach.

Could we quantify that somewhat? Is one security bug enough? Are 10?
Do we have a delegate that could audit and veto a package already
other than the release team? Is that the domain of QA or security?

Maybe any new package (one not in stable already) that has a security
bug could be automatically blocked from the next stable release until
a source audit by some team (security? qa?) is done? Doing this for
every new package is probably too much to ask timewise but for any
package known to have one exploit already that seems prudent.

MfG
        Goswin



More information about the Secure-testing-team mailing list