Evaluate osv.dev

[woodruffw]

Per @di: The final deliverable version of pip-audit will not use osv.dev, but instead should use a (hitherto unimplemented) REST API provided by PyPI.

Since we'll need to consume that API, we should evaluate osv.dev and determine what we'd like to be different.

[di]

Here's the docs for the OSV API: https://osv.dev/docs/

[di]

Also the PyPI API will probably be additional fields on the Release API: https://warehouse.readthedocs.io/api-reference/json.html#release, but you tell me if that makes sense.

[tetsuo-cpp]

I've spent a bit of time today looking at OSV and playing around with the API.

I think the query method (specifically the ability to get vulnerabilities from a given package and version pairing) in the API does what we need for pip-audit so something that works similarly would be ideal. I figure that our logic is going to contain a list of package/version pairs, that we've fetched from a distribution or parsed from a requirements file, and we'll proceed to call the API for each one and assembly the output.

I think all of the information in the vulnerability schema is useful but at a bare minimum we'll need:

• id
• details
• version introduced
• version fixed

Those should give an idea of what the vulnerability is as well as the range of affected versions so that the user can remediate the issue by upgrading or downgrading as needed.

As for @di's suggestion that it can be added to the end of the version method, I think that makes sense and works for our purposes.

[woodruffw]

Thanks! We'll use this info to design an initial API adaptor.

[tetsuo-cpp]

One thing that I noticed recently is that the OSV vulnerability schema lists multiple version range. So there can be multiple start version introduced/version fixed pairs for a single vulnerability in the case where the same bug get re-introduced.

We'd want the PyPI API to work the same way for those types of vulnerabilities.