[PyPI] Data quality issue for `markdown2`

@alex reported this upstream to pip-audit:

pip-audit -r <(echo 'markdown2==2.4.2') --no-deps

Produces:

Found 1 known vulnerability in 1 package
Name      Version ID                  Fix Versions
--------- ------- ------------------- ------------
markdown2 2.4.2   GHSA-p6h9-gw49-rqm4

But GHSA-p6h9-gw49-rqm4 isn’t valid for 2.4.2 (it’s only valid for <2.3.6): https://github.com/advisories/GHSA-p6h9-gw49-rqm4

It looks like OSV has both GHSA-p6h9-gw49-rqm4 and its CVE alias, but with a missing “version fixed” for the GHSA version: https://osv.dev/list?ecosystem=&q=CVE-2018-5773

cc @di as well for visibility.

[oliverchang]

Fix has been merged. Thanks @woodruffw !

[oliverchang]

On GHSA-p6h9-gw49-rqm4, there’s no listed patch, which is what led to this missing “fix” property. I believe the correct course of action here is to figure out the right fix version and amend the GHSA entry.

Sounds good. I can look into a PR on GitHub’s side later today.

Not understanding the architecture of OSV that well: should OSV be merging these two reports into one, and therefore having the “fixed” data in either is sufficient?

My understanding of OSV (which might be very wrong!) is that it keeps all reports around, and only links them via alias sets. So on the client’s side, there’s an annoying ambiguity: we might deduplicate via aliases, only to have the “authoritative” record (which we choose semi-arbitrarily) be lacking some metadata. It’d be nice for OSV to do some kind of consistency checking between aliased reports, but I suspect that would require a lot of manual cleanup.

Right. We haven’t been able to come up with a good way to merge reports automatically. For now I think it makes sense to consider each report separately – clients can decide their appetitie/strategy for dealing with them.

Even in this case with https://github.com/advisories/GHSA-p6h9-gw49-rqm4 and the listed issue (https://github.com/trentm/python-markdown2/issues/285#issuecomment-439759467), it’s not actually perfectly clear if the underlying vulnerability is fully fixed, so it’s not necesarily the case that the PYSEC entry is more accurate.