Re: security-tracker: A proposal to significantly reduce reported false-positives (no affected-code shipped)
Hello Salvatore, sorry about the late reply, I was in MiniDebConf Maceió.
On Thu, 1 May 2025 at 06:24, Salvatore Bonaccorso <carnil@debian.org> wrote:
> 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'm currently traveling and don't have access to the list I previously checked
(will only reach that PC close to June).
But I think "nonissue" will work perfectly, at least as long as we also define
that <nonissue> will always result in the security-tracker (web UI, json) and
OVAL file (or alternatives we might generate in the future) showing the
package's binaries as "not-affected". Is this in line with what you discussed?
I'm asking because "nonissue" has a broader definition compared to
"not-affected-build-artifacts", and if "nonissue" is used for questionable CVEs
(e.g.: CVEs for elfutils or without security impact), then we can't end up in a
situation where "nonissue" is not evaluated as "not-affected", as this defeats
the whole purpose of the solution.
Thank you,
--
Samuel Henrique <samueloph>
Reply to: