Data quality issue with PYSEC-2024-225

[mgedmin]

The CVE ID
https://osv.dev/vulnerability/PYSEC-2024-225 (alias of https://osv.dev/vulnerability/CVE-2024-26130).

Describe the data quality issue observed
The source lists affected versions as 38.0 through 42.0.3, but osv.dev lists every version from 0.1 to 42.0.3 as affected.

Suggested changes to record
TBH I'm not familiar enough with the semantics of the data format to decide whether the bug is in the source, or in the import logic.

The source enumerates the affected versions directly, and then also defines two ranges: one for ecosystem versions from 38, until 40.0.4, and another for git commits from "0" to 97d231672763cdb5959a3b191e692a362f1b9e55. I don't know if "0" means "unknown" or if it means "the very first commit, whatever it was".

I don't think the osv importer should even look at git commits when it's been given an explicit list of affected versions.

Additional context
The aliased CVE record shows correct version ranges, and a synthetic git commit range that points to commits corresponding to releases, rather than to the actual commits that introduced and then fixed the bug.

[github-actions]

✨ Thank you for your interest in OSV.dev's data quality! ✨

Please review our FAQ entry on how to most efficiently have this addressed.

[mgedmin]

A tangential issue is that if osv.dev thinks every version before 42.0.4 is affected, it's missing some of the versions that exist, like 3.4.8. As a result tools like pip-audit do not include PYSEC-2024-225 among the vulnerabilities that affect cryptography 3.4.8.

Where does osv.dev get the full set of released versions? https://pypi.org/project/cryptography/#history lists all of those 3.x.y versions that are missing.

[jess-lowe]

The GIT ranges in the PYSEC OSV records are generated using the NVD conversion logic in this repository. When this record was generated we were using some different logic that essentially didn't care about what the introduced version was as there is a commit present in the references, which caused our parsers to interpret it as everything before the commit is affected (this is not true).

Now, the remediation is a bit trickier. To fix just this record, we'd just need to update the record in the upstream pypa advisory database with a PR either removing the GIT ranges entirely or updating them to the constrained range of the CVE alias.

Considering we already get coverage of the GIT information through our own conversion in the CVE- records, I don't really think it is necessary to have it in the PYSEC records, unless people are exclusively pulling the PYSEC data dumps and find the GIT information useful there.

I'd probably recommend dropping the GIT ranges - also in the wider PYSEC record generation - but that's something that @di, @westonsteimel and co might want to weigh in on :)