package-url / purl-spec

A minimal specification for purl aka. a package "mostly universal" URL, join the discussion at https://gitter.im/package-url/Lobby
https://github.com/package-url/purl-spec
Other
679 stars 157 forks source link

Proposal: `github-release` type #299

Open steiza opened 6 months ago

steiza commented 6 months ago

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:

pkg:github-release/advanced-security/gh-sbom@v0.0.10

To be explicit, here's a short definition for each of those purl fields:

There is some weirdness here to call out:

Alternative 1: use existing github purl type

The 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:

pkg:github/advanced-security/gh-sbom@v0.0.10

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 type

The problem with this approach is that it's very easy to have purl name collisions. Maybe this would look something like:

pkg:generic/gh-sbom@v0.0.10?download_url=https://github.com/advanced-security/gh-sbom/releases/tag/v0.0.10

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.

jhutchings1 commented 5 months ago

I'm a fan of the proposal to use a new type here as you propose, @steiza.