What's the difference between signing commits with SSH versus GPG?

Question

GitHub now supports SSH commit verification, so you can sign commits and tags locally using a self-generated SSH public key, which will give others confidence about the origin of a change you have made. If a commit or tag has an SSH signature that is cryptographically verifiable, GitHub makes the commit or tag "Verified" or "Partially Verified."

If you already use an SSH key to authenticate with GitHub, you can now upload the same or a different key pair’s public key to use it as a signing key. There is no limit to the number of signing keys you can add to your account. For more information, visit SSH Commit Verification in the GitHub documentation.

In the light of this recent event, I would like to know: What's the difference between signing commits with an SSH key versus a GPG key?

Note: Here is a similar question asking about the general differences between GPG and SSH. This question is specifically about the difference between using one or the other for signing purposes.

Answer 1

Functionally, both approaches provide equivalent cryptographic security. Both use robust digital signature algorithms and, provided the private key is secured, are believed to be effectively unforgeable.

SSH has the benefit that it's a little easier to forward your key to another machine. For example, at a previous employer, all development had to be done on a VM and source code wasn't allowed on laptops or desktops. Because of SSH agent forwarding, SSH would have been a little easier to use than GPG.

GPG has also come under some criticism for the quality of its cryptographic implementations, and there is definitely legitimate criticism of the use of SHA-1 for fingerprints and some of the encryption algorithms, the latter of which is not relevant here. (The use of SHA-1 for fingerprints will be fixed in an upcoming revision of the OpenPGP standard.) As a result, some people might prefer using OpenSSH because it typically has a better reputation for security, and it's usually already in place on most systems.

It's also a little easier to use OpenSSH with security keys because most security keys support FIDO2, and technically that's all that's required. OpenPGP implementations require some additional support, so the availability of OpenPGP on a security key is less likely.

However, OpenPGP has been around longer and has been supported longer by Git, so that makes it easier to use on older environments. Signing data also requires a more recent version of OpenSSH, again impeding its use on older environments. And finally, OpenPGP and GnuPG make it much easier to store and verify arbitrary keys, including, with GnuPG, trust on first use, whereas OpenSSH requires a specified list of allowed signers which must be maintained by hand.

Answer 2

Another difference is how you can use safely a (GPG/SSH) key across computers for signing your commit as you on all your platforms.

That means storing the key (GPG/SSH) in an online and synchronized Vault.
Otherwise, copying/reusing the same key on multiple computer would be a bad practice.

While it is possible to import/attach a key manually in a Vault, the only integration I know for signing Git commits is GitHub with 1Password and SSH keys (not GPG).

See Thomas Dohmke (CEO of GitHub) tweet:

Today (Sept. 8th, 2022), I am thrilled to announce our new integration with 1Password as well as our support for SSH commit verification.

Now developers can easily add their SSH key to verify commits and generate and store SSH keys right from the browser.

This refers to 1Password blog post "Sign your Git commits with 1Password" by Marc Mackenbac, where 1Password 8.9.4 or more will include a /Applications/1Password.app/Contents/MacOS/op-ssh-sign tool, and the capability to edit your ~/.gitconfig in order to use op-ssh-sign to sign your commits:

Your SSH key is managed in your online Vault (1Password for now, others might follow).