FWIW, have you considered making this a more general mechanism (eg: advisories instead of vulnerabilities)?

x-ref https://discuss.python.org/t/adding-a-mechanism-to-deprecate-a-published-project/13937/4?u=pradyunsg and https://github.com/pypi/warehouse/issues/345¹

FWIW, have you considered making this a more general mechanism (eg: advisories instead of vulnerabilities)?

Probably a good item for the FAQ. Basically: yes, but the OSV format doesn't support it and there is no schema like OSV that exists that we can point to that is as widely accepted by the ecosystem, so I'd be essentially making it up here, which seems wrong.

I think if that were to happen at some point in the future, it would be straightforward to add an advisories key here, but we could also potentially future-proof this by changing the keys to advisories/advisory-ids instead?

I think if that were to happen at some point in the future, it would be straightforward to add an advisories key here, but we could also potentially future-proof this by changing the keys to advisories/advisory-ids instead?

My 0.02c would be for a separate key, under the theory that advisories might differ substantially from vulnerabilities in both ID format and layout (since there's no OSV-like spec for them yet). But that's admittedly small and unlikely (since advisories should closely resemble vuln reports in form) 🙂

I'm not an author so I'll defer to y’all on picking the scope of this. This was a scope-creep/improvement that I could spot almost immediately during my first read, so that's why I asked.

This PEP's eventual goal of moving vulnerability data into a standardised API is worthwhile on its own though. :)

potentially future-proof this

I like the idea of future-proofing the new keys in some form like -- I'm spending mental energy on https://discuss.python.org/t/python-packaging-strategy-discussion-part-1/22420 right now, so sorry but that's literally all I'm gonna say for now. 😓

I gave this some more thought, and renaming everything to advisories/advisory-ids is IMO a good idea for the reasons @pradyunsg mentioned: future-proofing outweighs the likelihood of needing a substantially different format for advisories.

If we do need to mitigate a potential format difference, we could have each advisory body contains a type: string field where the default (absence) implies type: "vulnerability".