310

Is there an easy way to make Git always signs each commit or tag that is created?

I tried it with something like:

alias commit = commit -S

But that didn't do the trick.

I don't want to install a different program to make this happen. Is it doable with ease?

Just a side question, maybe commits shouldn't be signed, only tags, which I never create, as I submit single commits for a project like Homebrew, etc.

Arthur Cinader
  • 1,547
  • 1
  • 12
  • 22
MindTooth
  • 4,992
  • 4
  • 20
  • 15
  • 8
    The reason your alias did work is because you can't alias over a command that already exists. (related: http://stackoverflow.com/questions/5875275/git-commit-v-by-default http://stackoverflow.com/questions/2500586/setting-git-default-flags-on-commands http://stackoverflow.com/questions/1278296/is-there-any-way-to-set-a-flag-by-default-for-a-git-command) – Dan D. Apr 15 '12 at 10:59
  • 2
    Just for info: Rewrite all commits to be pushed to sign them: `git filter-branch -f --commit-filter 'git commit-tree -S "$@"' HEAD@{u}..HEAD` (I don't mean you should use this). – Vi. Sep 16 '12 at 16:35

6 Answers6

377

Note: if you don't want to add -S all the time to make sure your commits are signed, there is a proposal (branch 'pu' for now, December 2013, so no guarantee it will make it to a git release) to add a config which will take care of that option for you.
Update May 2014: it is in Git 2.0 (after being resend in this patch series)

See commit 2af2ef3 by Nicolas Vigier (boklm):

Add the commit.gpgsign option to sign all commits

If you want to GPG sign all your commits, you have to add the -S option all the time.
The commit.gpgsign config option allows to sign all commits automatically.

commit.gpgsign

A boolean to specify whether all commits should be GPG signed.
Use of this option when doing operations such as rebase can result in a large number of commits being signed. It may be convenient to use an agent to avoid typing your GPG passphrase several times.

That config is usually set per repo (you don't need to sign your private experimental local repos):

cd /path/to/repo/needing/gpg/signature
git config commit.gpgsign true

You would combine that with user.signingKey used as a global setting (unique key used for all repo where you want to sign commit)

git config --global user.signingkey F2C7AB29!
                                           ^^^

As ubombi suggests in the comments (and explain in "GPG Hardware Key and Git Signing", based on "How to Specify a User Id")

When using gpg an exclamation mark (!) may be appended to force using the specified primary or secondary key, and not to try and calculate which primary or secondary key to use.

Note that Rik adds in the comments:

If you're using something like a YubiKey (as recommended) you don't need to worry about the exclamation point because the only signing key(s) you should have available for a primary key-pair are:

  • the primary key itself, which should have a # after it indicating it's not available,
  • and the secret subkey with a > after it indicating it's a stub that points to the YubiKey as the only available signing key in its applet.

Only if you keep all your private keys available on your system (bad practice), then probably it would be a good idea to prevent auto-selection between available signing keys

user.signingKey was introduced in git 1.5.0 (Jan. 2007) with commit d67778e:

There shouldn't be a requirement that I use the same form of my name in my git repository and my gpg key.
Further I might have multiple keys in my keyring, and might want to use one that doesn't match up with the address I use in commit messages.

This patch adds a configuration entry "user.signingKey" which, if present, will be passed to the "-u" switch for gpg, allowing the tag signing key to be overridden.

This is enforced with commit aba9119 (git 1.5.3.2) in order to catch the case where If the user has misconfigured user.signingKey in their .git/config or just doesn't have any secret keys on their keyring.

Notes:

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    That's really cool. Is there an easy way on github do something like git describe without having to download the hole repo? –  Apr 28 '14 at 20:09
  • 33
    You don't need to sign your private experimental repos... but why wouldn't you? – Andy Hayden Apr 29 '16 at 21:59
  • 2
    Don't forget `!` after key id. Like `git config --global user.signingKey 9E08524833CB3038FDE385C54C0AFCCFED5CDE14!` – ubombi Nov 22 '21 at 12:53
  • 1
    @ubombi why? I am not familiar with that syntax (or do not see `!` in https://stealthpuppy.com/signing-git-commits-for-sweet-verified-badges/ for instance) – VonC Nov 22 '21 at 13:14
  • 1
    @VonC, [Here is why I use it](https://vitalii.kozlovskyi.dev/posts/gpg-hardware-key-and-git-signing/). TL;DR: `!` forces gpg to use exactly the key you specified, otherwise the behavior is quite undefined. (issue exists when you start using subkeys) – ubombi Nov 22 '21 at 14:34
  • @VonC, [gpgdoc](https://www.gnupg.org/documentation/manuals/gnupg/Specify-a-User-ID.html) > When using gpg an exclamation mark (!) may be appended to force using the specified primary or secondary key and not to try and calculate which primary or secondary key to use. – ubombi Nov 22 '21 at 14:37
  • @ubombi Excellent! Thank you for the feedback and references. I have included your comment (and those references) in the answer for more visibility. – VonC Nov 22 '21 at 14:39
  • If you're using something like a YubiKey (as recommended) you don't need to worry about the exclamation point because the only signing key(s) you should have available for a primary key-pair are the primary key itself, which should have a `#` after it indicating it's not available, and the secret subkey with a `>` after it indicating it's a stub that points to the YubiKey as the only available signing key in its applet. Only if you keep all your private keys available on your system (bad practice), then probably it would be a good idea to prevent auto-selection between available signing keys. – Rik Jun 12 '22 at 07:50
  • @Rik Thank you for this feedback. I have included your comment in the answer for more visibility. – VonC Jun 12 '22 at 08:33
269
git config --global user.signingKey 9E08524833CB3038FDE385C54C0AFCCFED5CDE14
git config --global commit.gpgSign true

Replace 9E08524833CB3038FDE385C54C0AFCCFED5CDE14 by your key ID. Remember: It's never a good idea to use the short ID.

UPDATE: Per a new git edict, all config keys should be in camelCase.

Theodore R. Smith
  • 21,848
  • 12
  • 65
  • 91
Felipe
  • 16,649
  • 11
  • 68
  • 92
  • Did you just copy and paste this from [VonC's answer](http://stackoverflow.com/a/20628522/2812842)? – scrowler May 15 '16 at 23:59
  • 26
    No. As you can see in the edition history someone has added my example in his answer. ED5CDE14 is my own personal key. But no problem. – Felipe May 16 '16 at 05:05
  • 8
    Bizarre. I will revert the change tomorrow as it looks bad for you – scrowler May 16 '16 at 05:06
  • How do you find your key signing ID? also, is having just 1 GPG key for all my git repos bad? because I'd much prefer to not have to deal with 4 diff keys in pretty connected projects. – MarcusJ Jan 13 '17 at 03:27
  • 1
    This might help Linux users: In order to make it work in some occasions (for example on Vim, using a key stored in a smart card that requires PIN entry) I had to edit `~/.gnupg/gpg-agent.conf` and add `pinentry-program /usr/bin/pinentry-gtk-2` (following this guide https://wiki.archlinux.org/index.php/GnuPG#pinentry ) – Iakovos Feb 06 '17 at 11:21
  • 3
    @MarcusJ `gpg --list-keys --fingerprint` will show you the long form of the keys (I suppose you have to remove the spaces by hand). – Suzanne Soy Aug 26 '18 at 16:06
  • 1
    @SuzanneSoy `gpg --list-keys --keyid-format long` shows the long format with no spaces :) – Ictus Mar 17 '22 at 05:35
50

Edit: As of Git version 1.7.9, it is possible to sign Git commits (git commit -S). Updating the answer slightly to reflect this.

The question title is:

Is there a way to “autosign” commits in Git with a GPG key?

Short answer: yes, but don't do it.

Addressing the typo in the question: git commit -s does not sign the commit. Rather, from the man git-commit page:

-s, --signoff
Add Signed-off-by line by the committer at the end of the commit log message.

This gives a log output similar to the following:


± $ git log                                                                                 [0:43:31]
commit 155deeaef1896c63519320c7cbaf4691355143f5
Author: User Name 
Date:   Mon Apr 16 00:43:27 2012 +0200

    Added .gitignore

    Signed-off-by: User Name

Note the "Signed-off-by: ..." bit; that was generated by the -s flag on the git-commit.

Quoting the release announcement email:

  • "git commit" learned "-S" to GPG-sign the commit; this can be shown with the "--show-signature" option to "git log".

So yes, you can sign commits. However, I personally urge caution with this option; automatically signing commits is next to pointless, see below:

Just a side question, maybe commits shouldn't be signed, only tags, which I never create, as I submit single commits.

That's correct. Commits are not signed; tags are. The reason for this can be found in this message by Linus Torvalds, the last paragraph of which says:

Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less. It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need one signature to make all the commits reachable from that one be effectively covered by that one. So signing each commit is simply missing the point.

I'd encourage a browse of the linked message, which clarifies why signing commits automatically is not a good idea in a far better way than I could.

However, if you want to automatically sign a tag, you would be able to do that by wrapping the git-tag -[s|u] in an alias; if you're going to do that, you probably want to setup your key id in ~/.gitconfig or the project-specific .git/config file. More information about that process can be seen in the git community book. Signing tags is infinitely more useful than signing each commit you make.

simont
  • 68,704
  • 18
  • 117
  • 136
  • 1
    I ment using the -S which does sign with a GPG-key :P Sorry. Also, thanks. – MindTooth Apr 16 '12 at 13:22
  • 89
    "Signing each commit is totally stupid." -> What is better way to secure commits when there is a "rat" developer who likes pushing commits with faked author and committer? Unless there is some hook magic on the server he can direct `git blame` to whoever he wants. – Vi. Sep 16 '12 at 16:39
  • 1
    @Vi. If you don't trust the author to correctly sign the code she's committing, why do you trust their code? That aside, signing *one* of the commits is sufficient to sign *all* of them, based on the `SHA1` chain, and [can be used to show ownership, similarly to the `sign-off` feature](http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for). Signing *all* commits *automatically* defeats the purpose of the signature as described in the answer, and is pointless (as signing once is sufficient). – simont Sep 17 '12 at 01:40
  • 12
    0. [an article](http://mikegerwitz.com/docs/git-horror-story.html), 1. "is sufficient to sign all of them" -> How to tell "I claim that _this_ is really _my_ diff (but unsure about any previous and further commits). I want to put a signature on _my_ commit without asserting anything about commits I pulled from the central server/whatever. 2. In untrusted environment there still should be a reliable tool to find out who is guilty. If the server checks that all commits are signed with key of committer's email, it is hard to fake a commit (if you secure your computer well). – Vi. Sep 18 '12 at 13:22
  • 9
    Signing one commit is sufficient if code never changes. Once you add more commits, you'll need more signatures. Signing a tag is marking everything OLDER than that commit. If you need fine grained verification as the commits are coming, it makes sense to sign each commit. Otherwise you'd have to use a lot of tags, which would just clutter up the repo. On authenticated remote git repos, you have to give your password or ssh key every time you push a commit, not only when you push tags. This is a similar situation. – Hans-Christoph Steiner Sep 18 '12 at 20:28
  • 6
    This answer is still out of date and self-contradictory - e.g. the bits towards the end which claims that "Commits are not signed; tags are." – Adam Spiers Apr 15 '14 at 13:22
  • 32
    I feel like Linus is kind of missing the point. He seems to have an entirely different use case for signed commits in mind than the OP in that thread. (Verifying the integrity of the entire project, vs verifying the authorship of a single commit.) – Ajedi32 Jan 11 '16 at 18:16
  • 4
    "Yes, but don't do it" -- why? There is no reason for this. It makes perfect sense to automate this. It is similar to signing your email by default. You should make sure that your password is forgotten instantly or after a reasonably short timeout, but otherwise you're good. –  Apr 05 '16 at 19:45
  • 9
    Now that the `commit.gpgsign` option (to always sign every commit) is available in git, does that mean the argument has been lost? Why would this be offered if it was "totally stupid"? – Andy Hayden Apr 29 '16 at 22:10
  • 15
    -1 for "Yes, but don't do it." The answer should just be a flat out "YES". Signing commits proves the author, something that otherwise can be lied about in the commit. – Urda Jun 11 '16 at 00:12
  • 9
    As is typical of Linus: loud, tons of opinions, many of them wrong, but the throngs of devs who follow him wouldn't dare question his word. It's a shame, really. – William T Froggard Nov 10 '17 at 17:50
15

To make auto signing work pre git version 2.0, you'll have to add git alias for commit.

# git config --global alias.commit "commit -S"
[alias]
    commit = commit -S
malat
  • 12,152
  • 13
  • 89
  • 158
Shubham Chaudhary
  • 47,722
  • 9
  • 78
  • 80
14

First setup the public key using which you want to sign all your commits , tags and push. To get the public key, use the following command

% gpg --list-keys --keyid-format=short
/home/blueray/.gnupg/pubring.kbx
-------------------------------
pub   rsa3072/F6EED39A 2021-12-25 [SC] [expires: 2023-12-25]

In this case the public key is F6EED39A. Now run the following commands.

git config --global user.signingkey F6EED39A
git config --global commit.gpgSign true // sign all commits
git config --global tag.gpgSign true // sign all tags
git config --global push.gpgSign true // sign all push

Please note that, If you use push.gpgSign true, the push will fail if the server does not support signed pushes. An alternative is to use:

git config --global push.gpgSign "if-asked"

Which says, sign all push if the server supports it.

Now all your commits , tags and push will be signed by your given public key automatically.

Sometimes you may need to override these settings.

For commits, use git commit --no-gpg-sign -m "Unsigned commit"

For tags, use git tag --no-sign <tag-name>

For push, use git push --no-signed or, --signed=false.

Ahmad Ismail
  • 11,636
  • 6
  • 52
  • 87
  • 2
    Signing pushes is a good addition. This feature is easily forgotten. I should add that it can also be set to `if-asked`. This way pushes will only be signed when the server supports it. – Iizuki Sep 02 '22 at 09:04
0

You need to make clear that if you sign a commit or tag, that you do not mean that you approve the whole history. In case of commits you only sign the change at hand, and in case of tag, well.. you need to define what you mean with it. You might have pulled a change which claims it is from you but was not (because somebody else pushed it to your remote). Or it is a change you dont want to be in, but you just signed the tag.

In typical OSS projects this might be less common, but in a enterprise scenario where you only touch code every now and then and you don't read the whole history it might get unnoticed.

Signing commits is a problem if they will get rebased or cherry-picked to other parents. But it would be good if a modified commit could point to the "original" commit which actually verifies.

eckes
  • 10,103
  • 1
  • 59
  • 71
  • 3
    Rebasing is like lying. It should be used exceedingly sparingly. The other thing is that committing with a signature is "signing off" code, so be double sure that it's a) not anti-CYA and b) not wasted effort. –  Jan 13 '14 at 01:18
  • 15
    @Barry “Rebasing is like lying. It should be used exceedingly sparingly” – this is just not true. Rebase-based workflows are just as valid as merge-based workflows. Rebasing is way too powerful to be used sparingly. – Lukas Juhrich Oct 24 '15 at 09:52
  • 2
    When using this exclusively with GitHub that's not a problem, the merge commits will not be signed by you, as GitHub does not support this. The advantage of signing every (non-merge) commit in this environment, is it makes it very obvious when a rogue commit was added via a PR as it will not be signed with your GPG key. – Arran Cudbard-Bell Nov 17 '15 at 16:42
  • 3
    "It is dangerous if you sign a commit or tag (both will sign the whole history) that you might have pulled a change which claims it is from you" If you're only signing a commit though I wouldn't interpret that as an endorsement of every commit reachable from yours. You're not necessarily stating that those past changes are valid or endorsed by you, only that you created a commit based off of those changes. (Though with a tag, I agree you are indeed signing off on all commits reachable by the tag.) – Ajedi32 Jan 11 '16 at 18:39
  • Do you mean that when you rebase it retroactively signs commits by you (even if they were previously unsigned)? Or do you mean the other way: signed commits that are then rebased still have the original signature (even though the changes are potentially tainted)? – Andy Hayden Apr 29 '16 at 22:05
  • 1
    @ArranCudbard-Bell Just as an update, merge commits are signed by you if you set `commit.gpgsign` to true as suggested by @VonC – Jay May 25 '16 at 03:29
  • @Wade, not on GitHub. It doesn't have your private key, and I don't believe git will sign the commits retrospectively. – Arran Cudbard-Bell May 25 '16 at 03:30
  • @ArranCudbard-Bell depends if you merge in IDE and push or use the Github Gui. I guess normally you need to test locally frist so pushing from IDE is a common thing. – eckes May 25 '16 at 09:42
  • @ArranCudbard-Bell Yeah, github never prevented anyone from committing merges locally… – binki Sep 28 '16 at 05:18