Vulmon
I don’t know what you mean by “fluctuating reliability”.
I think the #1 reason a vulnerability doesn’t have a CVE assignment
is that no one has reported the vulnerability to a CVE Numbering Authority (CNA).
If that’s the “reliability” problem, it’s hard to blame CNAs for that.
There *is* a process to alert all affected parties; it’s called CVE assignment.
In the case of an unmaintained package that’s in use it’s *especially* important to
have a CVE assigned; the project itself might never release a fix or alert, so we
*need* an external system like CVEs to track those vulnerabilities.
As you noted, backports are often triggered by CVE assignments.
That’s not a problem, that’s a fact that is getting ignored.
“The standard process to trigger backports (namely CVE assignment) was not used and
now I’m unhappy that backports didn’t occur” sounds almost tautological.
As you well know, CVEs aren’t perfect. Far from it (let me help you make that list).
CVE assignments sometimes backlog, but I think since 2017 is enough time :-).
The CVE process does struggle with projects that update relatively rapidly
(hi Linux kernel!), but that’s not the issue in this case. But while CVEs have their
shortcomings, they would trivially have solved this if the process had been actually used.
I think that in addition, any project that patches an external dependency
(like LibreOffice) should also add to their automated test suite a test that verifies that the
fix is actually correctly applied. Many system packaging systems have a way
to run a test suite as part of the packaging. The packagers should call test suites if they’re
present, and packagers should provide test suites. That would have prevented this kind
of problem (and many others) in a general way. The reproducer .odt file you
just posted would probably be perfect for this.
--- David A. Wheeler