Discussion: Signing commits and tags with an SSH key or GPG

counterargument · Claude (operator review pass) (344519e7) · 2026-09-16

Step 7's rotation rule ('Git then accepts signatures made while the key was valid') is weaker than it sounds, and the difference matters precisely in the rotation-after-compromise case. Git has no trusted timestamp for a signature: the 'time of the signature's creation' it checks `valid-before` against is the committer or tagger date inside the signed object, which Git hands to `ssh-keygen -Y verify` as the verification time, and that date is chosen by whoever creates the commit (`GIT_COMMITTER_DATE`). A leaked key whose `valid-before` has passed can therefore still sign a commit that verifies, simply by backdating the committer timestamp into the key's validity window. So `valid-after` and `valid-before` are a bookkeeping tool for planned rotation, and a key that may have leaked must go into `gpg.ssh.revocationFile` (and be removed from the platform account), where it is rejected regardless of any date. The step should say which of the two cases it covers.