Describe the bug
The gh release verify and gh release verify-asset commands hard-code a sha1: prefix when constructing the digest identifier for a release tag's commit SHA:
GitHub is rolling out support for repositories that use SHA-256 object IDs for git commits. For those repositories the ref returned by the GitHub API is a 64-character SHA-256 hash, not a 40-character SHA-1 hash. Labeling that value with a sha1: prefix in user-facing output (and in the attestation lookup) is misleading and incorrect, and it will cause attestation lookups to fail once SHA-256 repositories are supported end-to-end.
Affected version
gh version 2.92.0 (2026-04-28)
https://github.com/cli/cli/releases/tag/v2.92.0
(Affects trunk as well.)
Steps to reproduce the behavior
- Run
gh release verify <tag> (or gh release verify-asset <asset> --tag <tag>) against a release in a repository.
- Trigger an error path that surfaces the digest (e.g., a tag with no attestations).
- Observe that the digest is always prefixed with
sha1:, regardless of the underlying ref algorithm.
Expected vs actual behavior
- Expected: The digest prefix matches the algorithm of the ref returned by the GitHub API —
sha1:<digest> for SHA-1 repositories and sha256:<digest> for SHA-256 repositories.
- Actual: The prefix is always
sha1:, even for refs that are clearly SHA-256 (64 hex characters).
Logs
N/A — this is a correctness issue in user-facing output and in the attestation API lookup parameters, not a runtime crash.
Motivation / proposed fix
Support is coming for GitHub repositories that use SHA-256 commit digests, and these commands will need to handle both algorithms once that support lands. The fix is small and self-contained: derive the digest algorithm from the length of the ref (40 hex chars → sha1, 64 hex chars → sha256) at both call sites, with sha1 remaining the default for backwards compatibility.
Happy to open a PR with the fix and added test coverage for both the SHA-1 and SHA-256 cases.
Describe the bug
The
gh release verifyandgh release verify-assetcommands hard-code asha1:prefix when constructing the digest identifier for a release tag's commit SHA:GitHub is rolling out support for repositories that use SHA-256 object IDs for git commits. For those repositories the ref returned by the GitHub API is a 64-character SHA-256 hash, not a 40-character SHA-1 hash. Labeling that value with a
sha1:prefix in user-facing output (and in the attestation lookup) is misleading and incorrect, and it will cause attestation lookups to fail once SHA-256 repositories are supported end-to-end.Affected version
(Affects
trunkas well.)Steps to reproduce the behavior
gh release verify <tag>(orgh release verify-asset <asset> --tag <tag>) against a release in a repository.sha1:, regardless of the underlying ref algorithm.Expected vs actual behavior
sha1:<digest>for SHA-1 repositories andsha256:<digest>for SHA-256 repositories.sha1:, even for refs that are clearly SHA-256 (64 hex characters).Logs
N/A — this is a correctness issue in user-facing output and in the attestation API lookup parameters, not a runtime crash.
Motivation / proposed fix
Support is coming for GitHub repositories that use SHA-256 commit digests, and these commands will need to handle both algorithms once that support lands. The fix is small and self-contained: derive the digest algorithm from the length of the ref (40 hex chars →
sha1, 64 hex chars →sha256) at both call sites, withsha1remaining the default for backwards compatibility.Happy to open a PR with the fix and added test coverage for both the SHA-1 and SHA-256 cases.