fix(signing): doctor-signing now catches identity/GitHub-account mismatches - #50
Merged
Merged
Conversation
…atches A signing key can pass every existing doctor-signing check - gpgsign on, key configured, key can actually sign, key registered on GitHub - and commits STILL render "Unverified" (reason: no_user) if git's user.email isn't a verified address on the same GitHub account that owns the key. GitHub can attribute the cryptographic signature but not the commit identity, and none of the prior checks catch this: it's a silent gap between "signing works" and "commits verify." Found live: today's session signed several commits correctly under a git identity (clauderobert@nios.net) that wasn't a verified email on the account (githubrobbi) the configured key is registered to. doctor-signing reported fully green the whole time; only gh api .../commits caught it after the fact. Adds the missing check: user.email against `gh api user/emails`. Same graceful-degrade posture as the existing GPG-key-registration check (advisory info note, not a hard fail, when the token lacks the user:email scope) so this stays a soft, informative check consistent with the rest of the doctor. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
just doctor-signingis the readiness checklist ADOPTING.md's step 5.3 says to run "green for every committer" before turning on therequired_signaturesbranch-protection rule. It had a blind spot: a key that signs correctly and is registered on GitHub can still produce commits that render Unverified on GitHub (reasonno_user) ifgit config user.emailisn't a verified address on the same GitHub account the key is registered to. None of the existing checks catch this - they all passed.clauderobert@nios.net, but the signing key is registered to thegithubrobbiGitHub account, whose verified emails don't include that address.doctor-signingreported fully green throughout; only checkinggh api .../commitsafter the fact caught it.user.emailagainstgh api user/emails. Same graceful-degrade posture as the existing GPG-key-registration check (advisory info note, not a hard fail, when the token lacks theuser:emailscope).Test plan
just doctor-signinglocally after fixing the identity that caused today's incident - new check reports correctly (degrades to an info note here since the localghtoken lacksuser:emailscope, same posture as the pre-existing GPG-key check).lint-fast+lint-pre-pushgates passed locally.Related
This repo's own
main-protectionruleset is missing therequired_signaturesrule that ADOPTING.md step 5.3 calls for - a separate, repo-settings-side follow-up (not a code change, needs to go throughgh apiwith elevated permission) tracked outside this PR.