Re: security-tracker: A proposal to significantly reduce reported false-positives (no affected-code shipped)

* [Wed, Apr 03, 2024 at 11:11:20PM +0100] Samuel Henrique:
>On the proposed solution I also mention that we can use the "(free text
>comment)" section to indicate that, while sticking to "not-affected", this
>would simplify things as no new value is needed. But parsing the cases where
>only the sources contain the vulnerable code might be a bit harder.
  
Not only it's the parsing harder, but it also is a "lesser" warning than 
an "affected" status.

>I'm curious though as to what is the usecase of that, no other Linux
>distribution specifies the case where only the source carries the
>vulnerability.

My impression is that Debian currently does, even if imperfectly, by 
marking the package as vulnerable and setting the unimportant bit.

>What would be the need for this as a user? If this is a need you have, 
>could you clarify it, please?

Definitively it isn't a need, I would call it an expectation. I used to 
recompile a lot of Debian packages, usually for backporting, and I guess 
I've always assumed that a package marked not-vulnerable would not bring 
the vulnerability back when, e.g., linked against a previous version of 
a library. Or, e.g., I would not consider not-vulnerable a package 
shipping a malicious example script.
But I concede that creating a binary-only tag has its own issues. For 
example, a vulnerability could only affect some architectures, and that 
means you should now differentiate not only per package name and "form" 
(source or binary), but also per architecture.

Cheers,
Gian Piero.