Allow using SSH keys to sign commits

[blimmer]

Git 2.34 now supports signing commits with SSH keys instead of GPG: https://github.blog/2021-11-15-highlights-from-git-2-34/#tidbits (see the first bullet point in the "tidbits" section).

It would be super cool to have this work with GitHub's existing "Verified Commit" tag, like it does with GPG keys.

[cgarrovillo]

gpg also often fails to sign commit data:
https://stackoverflow.com/questions/41502146/git-gpg-onto-mac-osx-error-gpg-failed-to-sign-the-data/41506446
https://stackoverflow.com/questions/39494631/gpg-failed-to-sign-the-data-fatal-failed-to-write-commit-object-git-2-10-0?noredirect=1&lq=1
https://stackoverflow.com/questions/41052538/git-error-gpg-failed-to-sign-data?noredirect=1&lq=1

[mosajjal]

Saves a lot of us to carry two keys instead of one. Also looks like the SSH key signature method doesn't have the "type confusion" issue of GPG

[anarsen]

You can use GPG keys for SSH auth too.

[craigfurman]

Your use case may vary, but personally I'm excited about this feature because signing commits (when mandated by company policy) is my only remaining usage of PGP, and I'm looking forward to putting it in the rear view mirror

[fazalmajid]

Yep. Apart from its general user-unfriendliness, it is also lined with security pitfalls:

https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

[maxgoedjen]

+1. Here's a demo commit that's got a valid signature using an SSH key: maxgoedjen/ssh_signature_demo@759243c, with a key listed in my profile

Basically GitHub just doesn't read the type of keys yet, but would love for this to get added soon (I've been putting off adding GPG support to Secretive for ages, but this works great with it pretty much out of the box.

In terms of verifying keys – it seems like it'd be reasonable for it to show as "verified" with any keys that have push access to your account, although personally I'd love the ability to mark specific keys as being used for push access, singing verification, or both.

[wiktor-k]

@marvinroger The post doesn't have anything about signing git commits with SSH (CTRL+F - "ssh" no hits) and nothing changed as of now (visit the link posted by Max: maxgoedjen/ssh_signature_demo@759243c).

[marvinroger]

@wiktor-k yes, I am aware of that, however the post relates to the feature asked by @krubenok in the first comment of this thread:

Allow a key (ssh or gpg) to be "retired". Commits signed with with that key before the retirement date should be shown as valid with a sub-status that the key has since been retired, any commits made after the retirement would be invalid. This means the relatively ephemeral nature of secretive or other hardware backed keys is basically moot.

[neo]

Thank you for sharing! With that update, do we still need to keep the expired public GPG keys in our account?

[jonaharagon]

It appears so, yes.

[krubenok]

Seems like some necessary pre-work to support SSH signing has shipped 🚢!

[jidicula]

Also, your SSH public keys are available at github.com/username.keys (unfortunately without their identifiers). This could potentially make it very easy for project maintainers to automatically create an allowed-signers file.

[jidicula]

I think we would need the key identifiers to be publicly visible for generating an allowed-signers file, though.

[unbeatable-101]

I think we would need the key identifiers to be publicly visible for generating an allowed-signers file, though.

Yep, it doesn't work without them.

[madhead]

Isn't it a privacy threat? One may use a private corporate email as an identifier. Leaking it may disclose the fact of employment, which may be undesirable.

[hilli]

One could switch between ssh signing keys, if that leak is undesirable.

[farski]

I learned about this new functionality in 2.34 from the GitHub blog, so I was quite surprised when I found out that GitHub doesn't actually support it yet.

[Menelion]

+1. Also, that will remove hassle caused by GPG for Windows users like me.

[unbeatable-101]

Don't worry, GPG is also a hassle to people not on windows 🥲

[davidstaheli]

Hi all. Thanks for this feedback because it helps us prioritize. The GitHub Repos team is also excited to see SSH commit signing support in Git. We're anxious for GitHub's commit validation to support it. Like what @farski said above, this is something that would have been great to support at the same time that Git began supporting it. We've recently expanded the GitHub Repos team and are still hiring to be more capable of that in the future. This issue is on our near-term backlog, but in full disclosure, we probably won't start working on it for 2-4 months. Commit security is an area that we want to give extra attention to during the next several months. @maxgoedjen, thanks for the good ideas about key management. If anyone has other suggestions on how repository or commit security can be improved, we'd love to hear them. We appreciate your perspective and knowing what is most important to you.

[dbrgn]

One way how the security with regards to SSH keys could be improved, would be if every SSH key could have a public name/reference in addition to the current (non-public) title. That key would then be included in the https://github.com/<username>.keys output. (Otherwise, if a user has multiple keys listed without any description, I have no idea whether I should trust some or all of them. Maybe I only want to trust the "work" key? Or only the "release signing" key?)

[politician]

@davidstaheli I am glad to hear that you want to focus on commit security. With many more organizations using GitHub Actions, Continuous Delivery, GitOps, etc. every day, git commits are increasingly becoming a huge attack vector. Commit signatures (as well as protected branches and required reviews) are a good way for security-conscious organizations to limit the attack surface.

Please, if you could pay extra attention to how keys are revoked, this is an important part where GitHub can add some value on top of what Git provides. My 2ç on this issue:

1. User revokes key/subkey on local machine
2. User uploads updated key containing revocation to GitHub
3. GitHub detects there is a revoked key/subkey that was used to sign commits previously and asks user if the key was compromised/lost and confirm a time and date from which to flag/unverify commits.
4. Before showing "unverified" status on GitHub, GitHub checks its cache to see if a commit hash was known as verified, so GitHub is now smarter than git log --show-signature

[taoso]

It finally works. Thank you 😄
https://github.blog/changelog/2022-08-23-ssh-commit-verification-now-supported/

[LunNova]

When this is implemented, it would be nice to be able to add keys which are trusted for signing but not trusted for pushing, instead of having a single list.

[fproulx-boostsecurity]

^ yeah, so that we one has the option to keep a similar Threat Model as SSH keys vs GPG keys.

For instance, I like to be able to git clone, fetch, etc. without having to take my yubikey out of my pocket, but for signing commits, that's another thing.

[RoyTinker]

Our org (using GitHub enterprise) would love to introduce required commit signing to all protected branches, but has only done so for a few security-sensitive repos, since rolling out GPG commit signing across the org is so cumbersome.

Support for SSH commit signing in GitHub repos would be so helpful.

[fiadliel]

Some thoughts on what might be some useful features here:

1. allow the option for GitHub-internal commits to be signed with an SSH key instead of GPG (also provide access to all previous public keys and valid periods of use). Configure per-repo and per-user/per-organization.
   This allows a single approach for validating all signatures in a repository.
2. allow a user or organization to provide an allowed-signers file (hardcoded, or potentially via a provided URL).
   This is especially for where organizations want full control over what keys are considered valid in their organization for signatures. e.g. an organization might only want signatures done via keys distributed on hardware tokens, and users should not be able to create a valid signature with a key generated any other way.
3. allow a user or organization to provide a key revocation list (hardcoded, or potentially via a provided URL).
4. potentially generate an allowed-signers sign automatically from uploaded public keys; this is what has been discussed so far in this issue.

[djmitche]

Hi there, a quick note on this topic -- the current behavior is

• GPG signed -- nice "Verified" badge
• Unsigned - no badge
• SSH signed -- scary "Unverified" badge

This creates the perverse incentive to disable signing of commits in order to avoid the false message to users that a repo contains malicious commits. In other words, this is making software security strictly worse.

While I understand that it will take some time for GH to show a "Verified" badge, could the hopefully-simpler change to show no badge for SSH-signed commits be made sooner?

[Mikaela]

Using vigilant mode I would prefer something like "unrecognised"

I have been using SSH to sign my commits for about two months and Gitea has supported verifying them for a month

[xIGBClutchIx]

Any updates on this?

[djmdjm]

Any update on when this is expected to launch?

[davidstaheli]

I apologize that this has taken longer than I anticipated. It has been released to GitHub's internal engineers for testing. Assuming all goes well, it should be released to everyone in the next two weeks (August 15).

[mhalano]

I think dogfooding is a wonderful practice

[fishtreesugar]

Is it delayed?

[mvdan]

Please don't ask for an update every two weeks. We would all like this featur sooner than later, but it's a very common time for holidays and travel right now. I would personally give it a rest until mid September at this point.

[jonaharagon]

I'm not sure if this has already been suggested, but I would appreciate a way to mark SSH and GPG keys as obsolete or revoked, such that commits made before they're marked obsolete remain Verified, but future commits made with the key are not, and the obsolete keys don't show up on https://github.com/JonahAragon.keys or https://github.com/JonahAragon.gpg.

It'd be especially handy once SSH signing here rolls out, so I can 'remove' my GPG keys from my account without unverifying every commit I've made in the past 2 years or so.

[marvinroger]

In case you missed it: https://github.blog/changelog/2022-05-31-improved-verification-of-historic-git-commit-signatures/

[fazalmajid]

That assumes there is a trusted commit time. GitHub can only know the time the commit was pushed to them and would have to use this timestamp and not the commit timestamp for the attestation.

[djmdjm]

git does provide direct support for revoking SSH signing keys, beyond the valid-after|before flags mentioned above:

     gpg.ssh.revocationFile
           Either a SSH KRL or a list of revoked public keys (without the
           principal prefix). See ssh-keygen(1) for details. If a public key
           is found in this file then it will always be treated as having
           trust level "never" and signatures will show as invalid.

Hopefully GitHub will surface a similar capability.

[davidstaheli]

Thanks for these great suggestions. We might get a first version released and then quickly follow up with some of these ideas. I'll try to share more details once the final scope is set. Though GitHub already recognizes when GPG keys are expired or revoked, I want to make sure we'll support the same for SSH, and if not in v1, how soon thereafter.

[abepolk]

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!

[krubenok]

https://github.blog/changelog/2022-08-23-ssh-commit-verification-now-supported/

🎊

[codemonkey85]

Am I missing something here? Looks like it works in theory but GitHub wants me to upload my SSH key, when I've already done that, and I've been using it for a while.

Here are a couple of screenshots to show what I mean.

[wyndon]

Did you read the link above?

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.

[codemonkey85]

Ahhh, thanks @wyndon. I didn't read that far down, or realize I had to upload it again as a signing key.

[paulmillr]

Update: fixed it; if you intend to use ssh-signed commits, you must create an empty allowedSignersFile and point git config to it. See replies to the post.

Today's release doesn't really work. GitHub worked a few months on a feature which is incomplete and is barely working.

I've signed a commit, pushed to the repo, all cool. Now, someone clones my repo, does git log --pretty='format:%GK', and what do they see?

error: gpg.ssh.allowedSignersFile needs to be configured and exist for ssh signature verification

Same error for git show. So basically if I clone 15 repos, I will need to manually add every contributor who uses ssh signature, to the allowedSignersFile. How am I supposed to know their ssh keys? Why doesn't GH automatically create the file for every repo?

As a side note, git log works great with PGP keys, and displays all keys without a requirement of adding them to your keychain.

[paulmillr]

Without auto-generated allowedSignersFile, the feature is useless because it breaks git log and git show.

curl <username>.keys is obviously a bad idea: you cannot realistically do this for every contributor of every project you're interacting with. In other words, GH stands in a good position of auto-generating the file, because they have the full social graph.

[jrmann100]

This project might be relevant? https://github.com/frankywahl/allowedSignersFile

[Raniz85]

If git log and git show breaks that's a bug in Git not GitHub.

Besides, the error message seems to indicate that you'll just have to create an empty file, configure Git to read it and then it'll work, but Git will show unverified commits - just as it does if you haven't imported the authors' GPG keys.

$ git verify-commit HEAD
gpg: Signature made Wed Aug 17 08:29:23 2022 UTC
gpg:                using RSA key 4AEE18F83AFDEB23
gpg: Can't check signature: No public key

You should not trust commits just because Git can display their signature. For it to be worth anything you must verify that the signature was made with a key that you trust.

git log --pretty="format:%GK" does not verify the signatures, it just shows which key was used to sign. You want git log --pretty="format:%G?" which prints an E if the signature could not be verified.

After importing and trusting GitHub's web-flow GPG key and then trying again I now get this:

$ git verify-commit HEAD
gpg: Signature made Wed 17 Aug 2022 10:29:23 CEST
gpg:                using RSA key 4AEE18F83AFDEB23
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   2  signed:   7  trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: depth: 1  valid:   7  signed:   0  trust: 2-, 0q, 0n, 2m, 3f, 0u
gpg: Good signature from "GitHub (web-flow commit signing) <noreply@github.com>" [full]

[paulmillr]

You should not trust commits just because Git can display their signature

Agree — though my concern was breakage of git log and git show, not semantics of %G? vs %GK. Creating an empty global allowed_signers fixed the issue.

Other users would still see the error if they don't create the file by default. This is a git issue and should be reported somewhere, but not GitHub's — empty file fixed it.

So, it's usable now.

[neo]

not sure if it's a bug, but I would like to point out that https://github.com/<username>.keys currently doesn't include the "signing keys" but only the "auth keys"

[fazalmajid]

Does the signature verification work with SSH CAs, which are supported in GitHub Enterprise, and if so is there an option to require the commit to be signed by a key that is certified by the repo’s org’s SSH key? Ideally I’d want the commits to be signed by an OpenSSH 8.2+ FIDO U2F ed25519-sk key certified by the CA key with a short-lived certificate so a stolen or lost Yubikey is not an issue.

[lpcalisi]

Hi @fazalmajid ! I've created a discussion for this topic some time ago

[lucasresck]

Thank you very much for this long awaited SSH signing feature!

Would it be possible in the future to implement some kind of isolation of the SSH signing key to specific repositories only? I'm thinking more in a solution to the problem of an untrusted remote machine in which you manage a specific repository (usually through an SSH deploy key).

[rosmanov]

Thank you for this feature!

Do you have estimations when it will be available in GitHub Enterprise?

[Menelion]

Thank you for the feature! I get no errors but I don't see a Verified icon on my commits either. Am I missing something? Unfortunately cannot show it to you so far, it's a private repo.

[AnthonyEnr1quez]

Will the rest API endpoint for creating an ssh key be updated to accept a ssh key type (auth/signing)?

https://docs.github.com/en/rest/users/keys#create-a-public-ssh-key-for-the-authenticated-user

[mhalano]

Include the signing keys with auth keys under https://github.com/user.keys it would be nice. I don't think there will be security implications.

[djmdjm]

Are FIDO SSH keys supported? I added a signing key to my account and pushed a commit that was signed using a FIDO key, but it shows up as "unverified" in the Github UI: openssh/openssh-portable@3a683a1

Verifying locally works fine:

$ git show --show-signature
commit 3a683a19fd116ea15ebf8aa13d02646cceb302a9 (HEAD -> master, origin/master, origin/HEAD)
Good "git" signature for djm@mindrot.org with ECDSA-SK key SHA256:JDubEpIXO0CfnM+iagFQce4MiJJDqTvgbBR80SuRwTQ
Author: Damien Miller <djm@mindrot.org>
Date:   Fri Aug 26 14:23:55 2022 +1000

    initial list of allowed signers

diff --git a/.git_allowed_signers b/.git_allowed_signers
...

[djmdjm]

I also notice that adding a SSH signing key to my account did not appear on my https://github.com/settings/security-log though subsequent actions do

[mhalano]

I also notice that adding a SSH signing key to my account did not appear on my https://github.com/settings/security-log though subsequent actions do

I don't see my actions related to SSH signing either

[mhalano]

Are FIDO SSH keys supported? I added a signing key to my account and pushed a commit that was signed using a FIDO key, but it shows up as "unverified" in the Github UI: openssh/openssh-portable@3a683a1

Verifying locally works fine:

$ git show --show-signature
commit 3a683a19fd116ea15ebf8aa13d02646cceb302a9 (HEAD -> master, origin/master, origin/HEAD)
Good "git" signature for djm@mindrot.org with ECDSA-SK key SHA256:JDubEpIXO0CfnM+iagFQce4MiJJDqTvgbBR80SuRwTQ
Author: Damien Miller <djm@mindrot.org>
Date:   Fri Aug 26 14:23:55 2022 +1000

    initial list of allowed signers

diff --git a/.git_allowed_signers b/.git_allowed_signers
...

It should work, but you must have your signing key added to GitHub.

[qbit]

Mine are working: qbit/xin@0ae779f (using FIDO) - I see a public_key.verify entry in my security log from when I added the pubkey.

[billmetangmo]

I am not able to sign commit with my ssh key. I got:

error: Load key "/tmp/.git_signing_key_tmpYlRvax": invalid format?
fatal: failed to write commit object

Does anybody has encountered this issue ?
I am using Linux on WSL . Don't know if it's related

[msladek]

No, it's not related to GitHub now allowing SSH key signing. It's an issue with the setup of your local machine.
Make sure you add your signing key defined in user.signingkey to the ssh-agent before committing.

[billmetangmo]

Oh you save my day :) !

[notshriram]

Thanks @msladek!
For people facing the same issue, here's github docs on how to add the ssh key to the agent.

[hilli]

I have updated the text on vigilant mode to reflect the new possibilities. PR here: https://github.com/github/github/pull/233947

[NickCao]

I noticed that from the view of users not logged in, commits signed with ssh are still marked as unverified, is this intended or a bug?

[NickCao]

Just checked again and now they are showed as verified.

[mhalano]

Can we have the sign SSH key on the https://github.com/user.keys file? I just could see the authentication SSH keys.