Understanding GitHub's implementation of GPG/SSH

[abepolk]

Select Topic Area

Question

Body

Hi, I'm trying to understand the difference between signing commits with SSH and GPG. From a GitHub docs article, it seems that GitHub still doesn't recognize the revocation or expiry of SSH keys, but it does for GPG keys. The article makes it sound like this is because of a conceptual difference between the two technologies, but this thread makes it seem like GPG is supported in this way just because that's how GitHub was historically set up. Am I missing something here, or perhaps misinterpreting the docs? Thanks!

[henry-AY]

Hey @abepolk,

Great question!
The key difference between GPG and SSH for Commit Signing is:

• GPG keys can expire or be revoked, which act as additional security measures compared to SSH keys. When a GPG key expires or is revoked, the key is no longer valid for signing new commits.
• Contrarily, SSH keys do not have a built-in mechanism for expiration or revoking. Thus, GitHub does not automatically detect or update their state. Once an SSH key is verified, commits signed with said SSH key will remain verified indefinitely.

The GitHub documentation states that GPG and SSH are supported for commit signing; however, it also describes GPG's advanced key management. This does not mean that Github doesn't recognize SSH's role in commit verification, however, it simply shows the difference in the capabilities between the two technologies.

Let me know if you have any more questions :)

[abepolk]

Thanks so much for your detailed response! I'm curious, why does a comment in this thread say that "git does provide direct support for revoking SSH signing keys" if SSH keys cannot be revoked? It also says "Though GitHub already recognizes when GPG keys are expired or revoked, I want to make sure we'll support the same for SSH." Am I mistaken that these posts imply that SSH keys can indeed expire and be revoked?

[henry-AY]

You're not mistaken for questioning this -- SSH keys do not have a built-in mechanism for expiration or revocation, unlike GPG keys. However,
Git provides a way to explicitly manually revoke trust in SSH signing keys, like using gpg.ssh.revocationFile (the same as mentioned in the thread). However, this doesn't mean that SSH keys inherently support expiration or revocation like GPG keys.

GitHub currently lacks native SSH revocation features, therefore commits signed with SSH remain "Verified" unless the key is explicitly manually removed or invalidated.

Hopefully, this clears everything up, let me know if you have any more questions :).

[Kazakio]

Hi @abepolk,

Great question! The main difference is that GPG keys can expire or be revoked, so GitHub can recognize when they’re no longer valid. On the other hand, SSH keys don’t support revocation or expiry, so once verified, they stay valid until you manually remove them.

This difference isn’t a GitHub limitation—it’s just how GPG and SSH were designed. GPG is better suited for commit signing because it’s built for cryptographic trust, while SSH is more about authentication and secure access.

Hope that helps clarify things!