Search code examples
gitgithubsshdigital-signaturegnupg

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


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.


Solution

  • 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.