Hello Salvatore, sorry about the late reply, I was in MiniDebConf Maceió. On Thu, 1 May 2025 at 06:24, Salvatore Bonaccorso <car...@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>
