Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
(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 user.name 'Madara Uchiha'
$ git config --global user.email [email protected]
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 way 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.
commit.gpgsign = true and I can ascertain no disadvantages. While it might be silly, it doesn't seem to be too expensive.
Oct 12, 2016 at 20:52