Hi! During triage, I realized I am sometimes a little hesitant in marking a package as no-dsa even though it's fairly obviously how it should be triaged. Take those two CVEs for example:
https://security-tracker.debian.org/tracker/CVE-2018-2767 mysql-5.5: fix should come with the bulk of fixes in the opaque next upstream release. so it's marked as "postponed" (which used to be no-dsa and is effectively the same). https://security-tracker.debian.org/tracker/CVE-2018-9918 qpdf: DoS by stack exhaustion, "chance of remote code execution". triaged no-dsa (minor issue) by the security team. i would normally mark that one as no-dsa as well. In both cases, i'm worried that marking the package as no-dsa/postponed will simply make it completely go away. The only safeguard against this is frontdesk's `lts-cve-triage.py` script, which *might* detect those as `unexpected_nodsa`, *only* if the security team eventually solves the issue. Shouldn't we have some mechanism to remind the LTS team of those pending issues somehow, regardless of normal security team activity? After all, we are to make our own judgement about no-dsa in the first place: if we don't act on that independently as well, it seems to me we'll be missing out on postponed work quite a bit... Note that the script does *not* detect `postponed` at all right now, which means postponed issues are in a state worse than `no-dsa` right now: they just go off the radar completely. Am I making any sense here? :) A.
