Re: Conflicting Information on CVE-2008-3699 Page
* Moritz Muehlenhoff:
>> The CVE-2008-3230 page seems to have the same problem. What would
>> need to be done to fix this? I may have some time to look at the code
>> and make it work better -- if someone can tell me where to start. Is
>> the code that generates these pages contained in the secure-testing
>> package?
>
> Thanks for the offer. I believe the addition of a new state similar to
> <unfixed> (e.g. <non-issue>) might be the best solution.
We currently have at least:
NOT-FOR-US
<not-affected>
unimportant
That's already too much choice, and it's really difficult to derive
clear semantics for all parts of the web page and the debsecan data
from that.
One thing that might work (but still requires code changes) is to use
"unimportant" only if there's a "fixed" version, and <not-affected> if
there isn't.
On top of that, we currently use <not-affected> and "unimportant" for
several, unrelated purposes:
- vulnerabilities not shipped in binary packages (only in the source)
- vulnerabilities on non-Debian platforms
- vulnerabilities in not-yet-uploaded versions
- non-vulnerabilities (design trade-off, bogus reports)
- vulnerabilities outside security support (browser crash, PHP safe mode issues)
There might be more stuff I've missed.
It's not quite clear to me how to reorganize all this. <non-issue>
might be one approach, but maybe this should be a per-CVE attribute
like REJECTED.
Reply to: