Proposal: github-release type

[steiza]

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/[email protected]

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

• type: github-release
• namespace: GitHub "owner" (e.g. a user or an organization)
• name: repository name
• version: the version string of the GitHub Release

There is some weirdness here to call out:

• In the purl spec the version is optional, but a github-release without a version doesn't make much sense.
• Today GitHub Releases are tied to a git tag, but we're thinking of ways to decouple GitHub Releases from git tags, because git tags are mutable.

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/[email protected]

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/[email protected]?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]

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