Commit signing in 2023 is kinda wack (opens in new tab)

Not as the creator intended, but Commit signing on GitHub is mostly an automatic thing at this point if you use pull requests and squash merges. The commits on the PR itself are unsigned, but the merge to the branch is attested and marked as signed by GitHub itself. Since you need to have permission at the time of merge, it's a rather trustworthy indication.

Here an example from Sentry's master which other than bot triggered reverts are all verified: https://github.com/getsentry/sentry/commits/master/

In theory, there is a solution to the PGP revocation issue that I think vibes with OPs desire:

Generate a long-lived root keypair (SC/C), the public key of which you add to the forge. You never sign directly with this. Instead you routinely generate new signing pairs. If compromised you hopefully only need to revoke the subkey so the blast radius is a lot smaller.

You could even do a three-tier one where you can keep the root key dead cold and literally lock it into a vault.

Last time I looked, this was not supported in GitHub, though; it only recognized signatures by explicitly trusted keys, not their signed subkeys.

> Key compromise happens, key loss happens, and identities change over time.

This problem is largely solved in cryptocurrency-land. You have a hardware device that does the signing, which is recoverable from a 24 word seed that is stored offline (plus a passphrase which can be memorized or stored online so that it's not catastrophic if someone gets to your seed).

I just found out that Ledger actually supports SSH/PGP: https://support.ledger.com/article/115005200649-zd

I simply include a base64-encoded PNG with the facsimile of my signature in the commit message, if I'm being really pushed to "sign my commit", it has about the same power of attestation as the cryptographic means. So far, I only had to do it once.

Why is this written so poorly?