signed_releases: why is github not sufficient?

[ljharb]

Specifically, nvm's "release" is just a tagged commit on github, which requires https, and the git SHA checksums to the file contents. Additionally, the release commit is GPG-signed.

Can someone help me understand what more I'd need to do to "sign" these releases, or have I met the requirement?

(separately, in a project published to npm, I believe that npm always automatically signs all published packages, so any npm package on the public registry should meet this requirement implicitly)

[david-a-wheeler]

Thanks! You can see more information here:

https://www.bestpractices.dev/en/criteria?details=true&rationale=true

It says this:

• The project MUST cryptographically sign releases of the project results intended for widespread use, and there MUST be a documented process explaining to users how they can obtain the public signing keys and verify the signature(s). The private key for these signature(s) MUST NOT be on site(s) used to directly distribute the software to the public. If releases are not intended for widespread use, select "not applicable" (N/A). {N/A justification} {Met justification} [signed_releases]
• Details: The project results include both source code and any generated deliverables where applicable (e.g., executables, packages, and containers). Generated deliverables MAY be signed separately from source code. These MAY be implemented as signed git tags (using cryptographic digital signatures). Projects MAY provide generated results separately from tools like git, but in those cases, the separate results MUST be separately signed.
• Rationale: This provides protection from compromised distribution systems. The public key must be accessible so that recipients can check the signature. The private key must not be on sites(s) distributing the software to the public; that way, even if those sites are compromised, the signature cannot be altered. This is sometimes called "code signing". A common way to implement this is by using GPG to sign the code, for example, the GPG keys of every person who signs releases could be in the project README. Node.js implements this via GPG keys in the README, but note that in the criterion we are intentionally more general: Node.js Release Team

Basically, it's there to counter compromised distribution systems.

[ljharb]

Thanks, that makes sense - so specifically, GPG-signed commits and/or tags would suffice for projects that distribute from git.