You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(ci): verify-signatures via GitHub API (was failing on every signed PR)
Root cause re-diagnosed: my previous `--no-merges` fix wasn't enough.
The workflow used `git verify-commit` LOCALLY on the runner. CI
runners have no GPG keyring with the signer's public key, so
verify-commit can't validate the signature and exits 1 for every
human commit — flagging it as "unsigned" regardless of actual sig
status.
Evidence: PR #89 commit `12b3310d` shows `%G?: G` (good signature)
locally, but the workflow rejected it.
Switched to GitHub's REST API verification:
gh api repos/$REPO/commits/$SHA --jq .commit.verification.verified
GitHub already verifies signatures server-side and exposes the result.
This is the source of truth that branch protection's
`required_signatures: true` setting already uses.
Three cases now handled distinctly:
- `verified: true` — PASS.
- `verified: false, reason: "bad_email"` — soft-pass with warning. The
signature IS valid (GPG/SSH checks out); only the GitHub-side
key→email UID binding is incomplete. The signer DOES control the
key. Hard enforcement requires the user to add the missing email
(typically the noreply form `<id>+<user>@users.noreply.github.com`)
as a UID on their signing key and re-upload to GitHub. Documented
in the failure message.
- Any other unverified state — HARD FAIL.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0 commit comments