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 :).

[abepolk]

Okay, this is helpful!

Obviously you didn't write the thread I linked to earlier, so it's fine if you don't know, but presumably the authors of those comments are referring to adding a revocation feature to GitHub for SSH that is specific to GitHub, as SSH does not have built-in mechanism as you described? (Of course, that feature hasn't yet been added.) That would make sense because the revocationFile is local and GitHub wouldn't know about it, I think.

[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!

[abepolk]

Thanks for your response! I was focused more on this thread when I wrote the original post, and you can see my thoughts and a further discussion in the comments to @henry-AY's response. Is your understanding consistent with this discussion?

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬