Signed Commits & GPG Verification
debt(d7/e3/b3/t7)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints note automated=no and the code_pattern describes absence of signing policy or branch protection rules — these are not caught by any automated linter or compiler. Reviewers must manually inspect commit verification status or audit branch protection settings; missing signing is invisible until someone looks. Not quite d9 because GitHub's UI does show 'Unverified' badges and branch protection can enforce it, but only if someone sets that up intentionally.
Closest to 'simple parameterised fix' (e3). The quick_fix describes a small set of git config commands (set signingkey, set commit.gpgsign true, add key to GitHub), touching developer machine config and GitHub settings. It's more than a single one-line patch (multiple config steps, key generation, uploading to GitHub, potentially configuring branch protection) but doesn't span multiple source files or require codebase refactoring — it's a localised configuration change.
Closest to 'localised tax' (b3). Applies_to is 'any' context, meaning every developer on the team must configure signing on their machines and CI must sign commits too. However the burden is primarily a one-time setup tax per developer rather than an ongoing structural weight on the codebase itself. It doesn't reshape architecture or slow down every future code change once configured, so it sits closer to b3 than b5.
Closest to 'serious trap' (t7). The misconception field explicitly states the canonical wrong belief: developers assume GitHub authentication already authenticates commits, not realising that git config user.email can be set to anyone's address without cryptographic proof. This directly contradicts how most developers reason about GitHub push authentication. Additionally, common_mistakes show multiple non-obvious failure modes (signing with a key not added to GitHub shows 'Unverified', optional signing provides no supply chain guarantee) that compound the confusion.
Also Known As
TL;DR
Explanation
Git signed commits use GPG (GNU Privacy Guard) or SSH keys to create a cryptographic signature proving the commit author controls the private key. GitHub shows a Verified badge on signed commits. Setup: generate GPG key, add to GitHub account, configure git to sign commits automatically (git config commit.gpgsign true). SSH signing (Git 2.34+): simpler — use the same SSH key as your GitHub auth key. Branch protection: require signed commits to prevent impersonation. Supply chain security: signed commits are essential for regulated environments where commit attribution must be verified.
Common Misconception
Why It Matters
Common Mistakes
- Signing with a key not added to GitHub — commits show as Unverified despite being signed.
- GPG key without expiry — keys should expire and be renewed.
- Not configuring git config gpg.format ssh for SSH signing — defaults to GPG.
- Not requiring signed commits on protected branches — optional signing provides no supply chain guarantee.
Code Examples
# Default git — no signing, identity unverifiable:
git config user.name 'Linus Torvalds'
git config user.email 'torvalds@linux-foundation.org'
git commit -m 'backdoor: add root access'
# Commit appears to be from Linus — no cryptographic proof required# GPG signing setup:
gpg --gen-key
gpg --list-secret-keys --keyid-format LONG
git config --global user.signingkey YOUR_KEY_ID
git config --global commit.gpgsign true
git config --global gpg.program gpg
# Or simpler SSH signing (Git 2.34+):
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
# Commits now show Verified on GitHub
# Require signed commits on main branch:
# Repository Settings -> Branches -> Require signed commits