Re: security-tracker: A proposal to significantly reduce reported false-positives (no affected-code shipped)
Hi Samuel,
On Sun, Apr 13, 2025 at 04:47:38PM +0100, Samuel Henrique wrote:
> Hello Salvatore,
>
> On Sun, 13 Apr 2025 at 16:32, Salvatore Bonaccorso <carnil@debian.org> wrote:
> > I have not gone to all details of your proposal, but the high level
> > view is IMHO as described in short above. For instance for the zlib
> > isues that would then move the entries from the ignored (which is a
> > substate of a no-dsa and apparently comercial security scanner are not
> > willing to parse or adapt to) to the more narrowed down and specified
> > substate of nonissue. In particular such a vunerability state could
> > exactly reflect as well per suite entry in case the state changes
> > between them.
>
> You mentioned this previously, which is a fair point. I believe one of the
> alternatives would work, what do you think?
>
> Quoting from that email:
> On Sat, 2 Nov 2024 at 20:02, Samuel Henrique <samueloph@debian.org> wrote:
> > On Tue, 29 Oct 2024 at 19:43, Salvatore Bonaccorso <carnil@debian.org> wrote:
> > > As mentioned in an earlier message: What I would love to see is to
> > > actually have a substate which makes the situation clear, and still
> > > beeing technically correct. I was envisioning something which would be
> > > a substate like we have for the substate of no-dsa (ignored,
> > > postponed).
> >
> > This sounds like the solution proposal A2, quoting it:
> > > ## A2) Add a new mutually exclusive state to the set:
> > "not-affected-build-artifacts"
> >
> > Would this be aligned to what you're looking for?
Yes the A2 would go in the direction we are thingking, internally we
have said to it a new "nonissue" state, which can apply as well at
suite entry levels (this was not possible with the unimportant severiy
as major drawback). The nonissue (or not-affected-build-artifacts as
you call it, but we can decide on a name once developing) state would
be a new state so we can cover exactly for instance the zlib case,
several curl cases were a feature is not enabled in a given suite, say
bookworm not, but above are. So as a purely example:
CVE-2024-9681 (When curl is asked to use HSTS, the expiry time for a subdomain might ...)
- curl 8.11.0-1 (bug #1086804)
[bookworm] - curl 7.88.1-10+deb12u9
[bullseye] - curl <ignored> (curl is not built with HSTS support)
Would become
CVE-2024-9681 (When curl is asked to use HSTS, the expiry time for a subdomain might ...)
- curl 8.11.0-1 (bug #1086804)
[bookworm] - curl 7.88.1-10+deb12u9
[bullseye] - curl <nonissue> (curl is not built with HSTS support)
Or
CVE-2023-28339 (OpenDoas through 6.8.2, when TIOCSTI is available, allows privilege es ...)
- doas <removed>
[bullseye] - doas <no-dsa> (Minor issue)
- opendoas <unfixed> (bug #1034185)
[trixie] - opendoas <not-affected> (Addressed via Linux kernel change)
[bookworm] - opendoas <ignored> (Minor issue, will be addressed via kernel change which isn't in 6.1 yet)
would become
CVE-2023-28339 (OpenDoas through 6.8.2, when TIOCSTI is available, allows privilege es ...)
- doas <removed>
[bullseye] - doas <no-dsa> (Minor issue)
- opendoas <unfixed> (bug #1034185)
[trixie] - opendoas <nonissue> (Addressed via Linux kernel change)
[bookworm] - opendoas <ignored> (Minor issue, will be addressed via kernel change which isn't in 6.1 yet)
Similarly we could handle CVE-2016-2568, CVE-2016-2781, CVE-2023-28339
in better ways than workaround.
Thos are just examples, and I think you have a more complete list (can
you share the CVEs so we can see how that would map into such a
state?)
> I think there wasn't a confirmation after this email.
Indeed, there were enough other things do do and that one had little
less priority (in terms of point of view obviously, everyone has it's
own priority list).
>
> > Hope this clarifies that you are not beeing ignored (heh ;-) no punt
> > intended here :)), which is as well quite important to me to let you
> > know.
>
> Definitely, I didn't mean to suggest that it's not as important to you as well,
> and thank you for replying!
Ack, done now.
Regards,
Salvatore
Reply to: