-
Notifications
You must be signed in to change notification settings - Fork 145
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
Proposal: github-release
type
#299
Comments
I'm a fan of the proposal to use a new type here as you propose, @steiza. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue is to suggest a
github-release
purl type, discuss the motivation, and list some possible alternatives.Motivation
At GitHub we're working on some improvements to GitHub Releases including the ability to make a release immutable (after which you couldn't add, change, or remove any of the assets on the release).
The immutability would be externally auditable by publishing an in-toto release attestation, which includes a purl. As an aside, the in-toto release attestation is a formalization of the npm publish attestation, which has been out for over a year and is working well for over 10,000 different npm packages.
npm publish attestations use the npm purl type, but GitHub Releases doesn't have a purl type.
Proposal
Add a purl type
github-release
. For example, https://github.com/advanced-security/gh-sbom/releases/tag/v0.0.10 would look like:To be explicit, here's a short definition for each of those purl fields:
github-release
There is some weirdness here to call out:
github-release
without a version doesn't make much sense.Alternative 1: use existing
github
purl typeThe problem with this is that the purl version is ambiguous. Today the purl spec says the version can refer to a commit hash or a git tag. We'd like it to refer to the release version string, but there's no requirement that the git tag and the release version string match (also the git tag is mutable). For example:
Could refer to https://github.com/advanced-security/gh-sbom/tree/v0.0.10, which is mutable, or (if we don't have a separate
github-release
type) https://github.com/advanced-security/gh-sbom/releases/tag/v0.0.10, which could be made immutable.Alternative 2: use
generic
purl typeThe problem with this approach is that it's very easy to have purl name collisions. Maybe this would look something like:
Any other package named
gh-sbom
(a fork, or an unrelated project) would end up with a similar-looking purl.Conclusion
Feedback welcome! If folks think this sounds good, I can write up a more formal pull request.
The text was updated successfully, but these errors were encountered: