[Secure-testing-team] Proposal: new tags

[Moritz Muehlenhoff]

Joey Hess wrote:
> Good idea on rejected and reserved. Not sure about not-for-us, part of
> the resaon we put the name of the software in parens is to aid finding
> bugs in software if it does end up entering Debian later on. 

I agree, leaving not-for-us is essential, we had a few issues that would
have slipped through if we hadn't had peer review through the svn-commits
list.

> > "INVALID" means that the bug report is known to be false.  For
> > example:
> > 
> > CVE-2003-0024
> > 	INVALID
> > 	NOTE: I have mailed Goran Weinholt <weinholt at debian.org> about this. 
> > 	NOTE: Goran Weinholt <weinholt at debian.org> tell me that aterm 0.4.2 was 
> > 	NOTE: never vulnerable to the problem described.
> > 	NOTE: this CVE is bogus.
> 
> Not sure how this is better than just the NOTEs by themselves.

I don't think this is needed. We can turn cases like these into REJECTED entries
through our Mitre contact. Florian, did you find many cases like this?

> > "IRREPRODUCIBILE" means that we have made reasonable effort to
> > reproduce the bug (mailing list research, rough source code audit, a
> > few exploit attempts), but we haven't found any evidence that it's
> > actually there (or has been fixed in the past).  For example:
> > 
> > CAN-2001-1429 (Buffer overflow in mcedit in Midnight Commander 4.5.1 allows local ...)
> >         IRREPRODUCIBILE
> > 	NOTE: I could track this down to this posting
> > 	NOTE: http://cert.uni-stuttgart.de/archive/vuln-dev/2001/11/msg00104.html
> > 	NOTE: This looks very obscure an does not contain useful information on how this
> > 	NOTE: was triggered and even then it's not a problem, as mcedit usage does not
> > 	NOTE: have a remote impact and is not suid
> 
> What's the value in having this be machine parseable?

We could just as well mark it "not-affected". If we can't reproduce it and the
maintainer agrees it most obviously won't affect Debian.

Besides, I think the main issue in this specific case is that it's not a
vulnerability. So simply add it to not-affected as well and consider it an
issue only for distributions that ship mcedit suid (i.e. none).

Cheers,
        Moritz