close
The Wayback Machine - https://web.archive.org/web/20220708115042/https://github.com/github/advisory-database/issues/10
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for purl #10

Open
stevespringett opened this issue Feb 22, 2022 · 1 comment
Open

Add support for purl #10

stevespringett opened this issue Feb 22, 2022 · 1 comment

Comments

@stevespringett
Copy link

@stevespringett stevespringett commented Feb 22, 2022

OSV supports Package URL, however, the OSV feeds in this repo do not appear to have purls. This request is to enhance all OSV files to include purl.

@greysteil
Copy link
Collaborator

@greysteil greysteil commented Feb 23, 2022

Definitely supportive of PURL, but this repo is a data source, and one that we want contributors to be able to edit directly. (We have some formatting improvements to make that easy, but that's the direction).

I'd be nervous about the duplication that adding PURLs here would create. The obvious concern is that the PURL could get out of sync and other (mandatory) package information. We could fix that with linting etc., but any duplication could make contributing harder. I imagine that's part of the reason the OSV spec calls out the schema is only designed for serving data, not storing it:

Again, this document is only about the JSON encoding the database serves to consumers, which could be applications or other databases. A database might store its entries in an entirely different format, or it might store them using this schema but in a more human-editable encoding, such as TOML or YAML.

I wonder if ☝️ speaks to a larger issue about the extent we are serialising the data in this repo for consumption vs. making it easy to edit it. We don't currently have a REST API for the data in this database (it's only available via GraphQL), but we plan to add one relatively soon. When we do it would allow us to separate the consumption concern from the contributing one a much more cleanly. This conversation would be trivial there - there would be no downside to us serialising PURLs in the API for anyone who wanted them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants