finding packages after no-dsa
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.
Reply to: