Dear security team, El 10/05/25 a las 16:14, Samuel Henrique escribió: > 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.
[snip] Would you be OK if we track the above proposal on a salsa issue in, https://salsa.debian.org/security-tracker-team/security-tracker/-/issues? If you are OK, I could volunteer to file the issue. But I'd be happy if Samuel files it too. As you are aware, the Debian LTS team is planning to hold a sprint during DebCamp 25. And if the above proposal is beneficial for you too (I think this would help us in the context of LTS and ELTS), it would be great to include it in the "target issues" to be addressed in the context of the sprint. Best, -- Santiago
signature.asc
Description: PGP signature
