Release tags are signed and verifiable
An unsigned tag proves nothing about who cut the release. Anyone with write access, or anyone who takes it, can point a tag at any commit. Forge verification reflects keys and identities registered with that forge and differs by signature format, so the portable evidence comes from git itself against a maintainer-controlled trust source.
Observable check
after git fetch --tags and importing the maintainer's published signing key, git tag -v <tag> on the newest release tag succeeds, and git cat-file -t <tag> prints tag, which means the tag is annotated rather than lightweight. Fetch the key from the forge the maintainer publishes it on: gh api users/{owner}/ssh_signing_keys or gh api users/{owner}/gpg_keys on GitHub, GET /users/:id/keys or /users/:id/gpg_keys on GitLab. An SSH signature verifies only against an allowed-signers file naming that key with the tagger's email, pointed at by gpg.ssh.allowedSignersFile; without it git tag -v reports a configuration error, which is the check failing to run rather than the tag failing to verify.
Where this comes from
- https://git-scm.com/docs/git-tag
- https://git-scm.com/docs/git-config
- https://github.com/ossf/scorecard/blob/main/docs/checks.md
Last read against these sources on 2026-07-28.
git-tag confirms annotated versus lightweight, -s signing through gpg.format, and -v. gpg.ssh.allowedSignersFile was read from the git 2.50.1 man page rather than the web page, which truncates: 'A file containing ssh public keys which you are willing to trust.' Scorecard Signed-Releases covers the why.