According to GitHub blog you can now sign your commits using your existing ssh key.
https://github.blog/2021-11-15-highlights-from-git-2-34/#tidbits
Following that: https://unix.stackexchange.com/questions/269188/use-my-ssh-key-to-sign-git-commits.
I've also been going through this documentation: https://git-scm.com/docs/git-config#Documentation/git-config.txt-gpgprogram, but it's very unclear how to use it.
I've set my gpg format to ssh and signining to true, so currently it is trying to sign it and fails. I believe I need to also set the user.signingKey but I can't figure out what the format is, i.e. git config --global user.signingKey <what-is-supposed-to-go-here>
?
I sort of have a second question to that. If in 1 year from now I format my PC and lose my keys, I would have no way to verify that those commits still belong to me. Is there a good standard for saving that key somewhere other than just dumping it into some online drive somewhere (where I'm likely to lose it anyways)?
Edit: I've at least managed to get gpg working. Following: Git error - gpg failed to sign data, my gpg was breaking with:
gpg: signing failed: Inappropriate ioctl for device gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device
Then adding export GPG_TTY=$(tty)
to bash, from "gpg: signing failed: Inappropriate ioctl for device" on MacOS with Maven, ended up working for me so it at least signs it using gpg.
Edit: Thought I managed to get it working but no. Following https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent, I created a new ed25519 ssh key.
After that you need git config --global gpg.format "ssh"
, along with git config --global user.signingkey "<key>"
.
I used ssh-ed25519 ASD9s8df79AASDa8sd79as7d9a8s7d89ASDASD98a7sd98a7sdASA/sd [email protected]
as the key, from ~/.ssh/id_ed25519.pub
.
But then I go to github and see:
Now I have no idea any more.
July 2022: I presented that new option here, where I mention:
The
user.signingKey
config for ssh signing supports either a path to a file containing the key or for the sake of convenience a literal string with the ssh public key.To differentiate between those two cases we check if the first few characters contain "
ssh::
" which is unlikely to be the start of a path.
However, it is possible that GitHub does not yet recognize an SSH-based signature.
This was mentioned in this thread and added to github-community/community
discussion 7744.
Early June 2022 you had:
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.
David Staheli (Product Manager at GitHub) answered:
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.
Update Aug. 2022:
SSH commit verification now supported
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 and 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.
Note: since Dec. 2022, GitLab (15.7) also supports commit signing with SSH.
And GitLab 16.9 (February 2024) has, for gitlab.com non-free (Premium or Ultimate)
Authenticate and sign commits with SSH certificates
Previously, Git access control options on GitLab.com relied on credentials set up in the user account. Now you can set up a process to make Git access possible using only SSH certificates. You can also use these certificates to sign commits.
See Documentation and Epic.