Show and verify commit signature status in gg - #2
Draft
faun wants to merge 2 commits into
Draft
Conversation
Verifying commits is a habit worth making visible, so surface each commit's signature state right next to the hash instead of having to run a separate verification pass. The comment records what the codes mean and the SSH caveat, since N reads as "unsigned" whether the commit really is unsigned or git simply lacks an allowed signers file to check against.
The column landed with the SSH caveat recorded but not resolved, so every line of gg output was preceded by an error and every commit read as N. Commits here are ssh-signed through 1Password, and git cannot attempt verification of an ssh signature without an allowed signers file, which makes the status indistinguishable from a genuinely unsigned commit. Configure the file and the column starts saying something: G for mine, N for unsigned, U for a signer I have no key for. The keys come from the ssh signing keys registered on GitHub rather than from ~/.ssh, because history carries four of them from different machines and GitHub has all four. Reading the local key alone would leave anything signed elsewhere reading U. The generated file stays out of this repo: it is public, and the moment it grew a colleague's key it would be publishing their address. Re-run the install step with --force after registering a new key. gg also drops the %G? token entirely when verification is impossible, so a machine without a signers file shows no column rather than a column of misleading Ns.
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Why
gggrew a%G?column so each unmerged commit's signature state sits next to its hash. That column could not work as shipped: commits here are ssh-signed through 1Password, and git cannot attempt verification of an ssh signature withoutgpg.ssh.allowedSignersFile. So everyggrun printederror: gpg.ssh.allowedSignersFile needs to be configured and exist for ssh signature verificationonce per commit and reported every commit asN, which is exactly what a genuinely unsigned commit reports. The column was worse than useless, it was misleading.What changed
install/01_configure_git_signing.sh(new): generates~/.config/git/allowed_signersfrom the ssh signing keys registered on GitHub. Writes viamktemp+mv, so a failed or empty API response leaves an existing file untouched, and skips with a message whengh,user.email, orgithub.useris missing. Re-run with./install.sh --force 01_configure_git_signingafter registering a new key.config/git/config: pointsgpg.ssh.allowedSignersFileat that file. Side benefit:git verify-commit,git log --show-signature, andgit merge --verify-signaturesstart working too.shrc/git.sh: newgit_can_verify_signatureshelper;gginterpolates the%G?token only when verification is actually possible, so a machine without the signers file shows no column rather than a column of misleadingNs.Keys come from GitHub rather than
~/.sshbecause history carries four signing keys from different machines and GitHub has all four. Reading the local key alone would leave anything signed elsewhere readingU. The generated file stays out of this repo on purpose: the repo is public, and the moment it grew a colleague's key it would be publishing their address. Other people's commits readingUis the correct outcome.Verification
./install.sh 01_configure_git_signingWrote 4 signing keysgit verify-commit HEADGood "git" signature for git@faun.me ..., exit 0%G?over last 300 commitsG, 33N(genuinely unsigned), 0U, 0error:linesggon a branch with unmerged commits* 44a439d G Faun: Split operations guide..., no errorsggprints no column and no errorgithub.user)zsh test/warp_test.zshConfirmed along the way that verification works despite
gpg.ssh.program = op-ssh-sign: git picks the verification backend from each signature's own payload rather than fromgpg.format, and usesssh-keygenfor ssh signatures.