8

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.

TTT
  • 22,611
  • 8
  • 63
  • 69
Nato Boram
  • 4,083
  • 6
  • 28
  • 58
  • 3
    I would imagine the barrier to entry is much lowered for those who are not already using GPG. – tripleee Aug 25 '22 at 15:16
  • 1
    I see a close vote for this being opinion based, but I'd say that's really splitting hairs to call it that. If the question was worded "What are the differences between" instead of "What's the advantages and disadvantages of" then I don't think anyone would consider this an opinion question. (And with that tweak the reader can decide for themselves whether each difference is a pro or con, or the answer can imply it.) If someone feels strongly about this then just go ahead and make that edit, but to close the question without that obvious wording tweak would be, IMHO, unfortunate. – TTT Aug 25 '22 at 17:35
  • @TTT They may not view it as opinion-based after that, but they may consider it too broad. SO is not for "list" type questions, either. – TylerH Aug 25 '22 at 18:38
  • @TylerH that assumes there are many differences. I feel like the answer to this question might be, none. What if there are just 2 differences? Is it too broad? – TTT Aug 25 '22 at 18:40
  • @TTT It's about whether the question is too broad, not whether the answer is too broad. "Name all the differences between these two products" is not an allowed question regardless of whether the answer is one line or would fill an entire book. – TylerH Aug 25 '22 at 18:44
  • @TylerH I'm not sure "products" is the correct way to think about it in the context of Git though. "Name all the difference between these 2 mechanisms of signing" would be a more accurate representation. Sort of like [this question](https://stackoverflow.com/q/292357/184546). (Though maybe you won't like that question either...) – TTT Aug 25 '22 at 21:14
  • @TTT Eh, explaining the differences between two specific commands within a program are different and far more specific compared to "advantages and disadvantages of a workflow methodology". One problem with advantage vs disadvantage is that what you consider an advantage, I might consider a disadvantage, etc. Hence the POB concern. – TylerH Aug 26 '22 at 13:44
  • @TylerH I fully agree with your last statement. ;) (I don't think it applies to *this* question though.) My main point here is that whoever votes to close should just edit the question. I guess I'll do it myself since no one else wants to. Done- no more opinions here! – TTT Aug 26 '22 at 13:57
  • @TTT - the dup uses the phrase "What are the differences" and the OP says, thats not the question. So I am still voting to remain closed as Opinion based or a duplicate – Rohit Gupta Apr 14 '23 at 12:46
  • @RohitGupta For historical context, when this question was posted it received at least one close vote for being opinion based, I believe that was because it asked for pros/cons, and some people automatically vote to close questions soliciting pros/cons. All of my comments above were about that alone, because apparently that day I was annoyed that we get so many close votes on valid questions with reasoning "opinion based", when most of the time a simple edit can fix that, and I did fix that. We have 2 good answers to the re-worded question which was asked. – TTT Apr 14 '23 at 16:54
  • 1
    @RohitGupta as for the recent closing of this question, I find that odd because this question is not asking the same thing as the linked question. In fact VonC answered both of these different questions with good different answers. I agree with OP's edit that this question is asking for the difference in the context of signing, which is not covered in the linked question, although it is mentioned that they can be used in that question, without covering the differences like the answers in this question. I voted to reopen this question. (Oh- apparently I have the power to single-handedly do it.) – TTT Apr 14 '23 at 16:58
  • @RohitGupta if you agree with the re-open, I think we (specifically a moderator) can probably clean up all of these comments after the first one. – TTT Apr 14 '23 at 17:02

2 Answers2

12

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.

bk2204
  • 64,793
  • 6
  • 84
  • 100
5

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:

gitconfig with 1password

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

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250