Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So someone peer reviewed my work, and he told me that I should always sign my commits and tags cryptographically. When asked why, he didn't know to explain it to me, and said "It's just a good thing to do".

Trying to avoid an obvious chimpanzee scenario, why should I really? Are there really so many distinct advantages and no disadvantages?

What are the practical reasons which would make me want to sign every commit and tag I make?

share|improve this question
I assume it's so that there's a paper-trail tying the commit to you. I've never signed a commit before though, either with git or any other source control system. If your peer believes there's a risk of fraudulent commits your company probably has bigger security problems. – James Sep 22 '13 at 10:28
@James: It's not company work, but I do participate in some open and closed source projects. – Madara Uchiha Sep 22 '13 at 10:29
@James: "bigger security problems" --- like what? Signing is a technical way of solving them isn't it? – zerkms Sep 22 '13 at 10:29
@zerkms I assumed the OP was talking about a private repository. Is the signature verified automatically? – James Sep 22 '13 at 10:32
6 is a starting point for the use case of signed commits and tags. – user40980 Sep 22 '13 at 12:53
up vote 56 down vote accepted

(This is largely based on A Git Horror Story: Repository Integrity With Signed Commits—a very good read, and more information than I could put into an answer.)

There are a number of ways in which a git repository can be compromised (this isn't a security flaw, just a fact of life—one should not avoid using git because of this). For example, someone may have pushed to your repository claiming to be you. Or for that matter, someone could have pushed to someone else's repository claiming to be you (someone could push to their own repository claiming to be you too). This is just part of life in a DVCS.

Just as an example:

$ git config --global 'Madara Uchiha'
$ git config --global

There, I've changed my git configuration to pretend I'm you. And now I can commit away and let those commits somehow make their into the production build, and it looks like you've done it.

With signing of the commits (and tags), one can prove that certain commits and tags were from you (and things that aren't signed shouldn't have made it into the production build). That's really the key to it all—by signing commits you've said it's your work.

The "your work" aspect is particularly important in the linux kernel (and thus git) that is occasionally hit with copyright lawsuits. By signing commits you say that you have the right to the software—it tracks the origin. It may be that you've got no access to the source that is being claimed as copyright and the claim is groundless. It may be that the company forgot that you were working for them a few years ago and under their direction added material to the kernel, or whatever.

There is some debate as to if every commit should be signed. From GPG signing for git commit? (back in '09), Linus wrote:

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.

Much more about the thoughts on signing in git can be read there too.

That said, it made its way into git anyways.

There seems to be a majority consensus that signing commits is unnecessary, but signing tags is very good. That blog post linked at the top suggests that one should sign everything anyways. As I said, there's some debate about if every commit is necessary or not.

The key to the "sign every commit" debate probably has to do with the workflow you use. Most people make a bunch of commits in their local repo, and then push that set. It should be sufficient to tag the final collection (assuming, that is, you make sure that all the changes are correct). If you are working in an environment where lots of single commits are moving around, the distinction between a tag and a commit becomes less… distinct—and signing commits may become more useful.

share|improve this answer
Interesting, thanks for the well thought out answer! I'll wait a while longer to see if someone has a different opinion and then accept yours if nothing serious comes up :) Thanks! – Madara Uchiha Sep 22 '13 at 20:24
It may be sufficient (to just tag the last one), but why wouldn't you just tag every commit? – hayd Apr 29 at 22:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.