Thursday 7 May 2009

Improved security with git and gitosis

So, I started working on Linux and one of my first tasks has been to learn to use git, the open source version control system used by, among others, Linus Torvalds. I'm familiar with a number of SCM systems but git has quite a lot of new stuff for me. I also installed gitosis for added security. Gitosis removes the need to create user accounts for everyone who needs to read or write to the repository, which improves security a lot. Setting it up had it's small quirks which meant I couldn't use the otherwise excellent guides to the point. But I did get there eventually.

Anyways, what I wanted to do was to check that the user is who he says. By simply saying "git config && git config Fake" a user can hide his identity - in practice allowing him to add what he wants to the repository as long as he has write access. Also, there is no extra security for anything else. For instance if you have conditional hooks in your git repository, you can't just the user id for access rights.

The solution is to use gitosis and check that the user really is who he says he is. I already asked this question in stackoverflow and then ended up solving the problem myself. The solution requires fixing gitosis, reinstalling it and the adding a pre-receive hook to the git repository. Not overly complicated, but hopefully someone could add that fix to the "official" gitosis code as well.

This solution verifies that the user email address used to create the ssh key for gitosis matches the address the user is using which should be pretty secure. This way the repository history is correct and the culprits can always be tracked down.


  1. It seems you want to prevent anyone pushing commits that he himself has not authored/committed.

    Which means I can't pull changes from your "working set" repo/branch, review them, and then push them to a more "sacred/canonical" repo/branch, because they will have your email as author/committer.

    Doesn't sound like git anymore then -- I smell SVN-itis ;-)


  2. Sometimes it is just necessary to make sure that right people do the changes. You just don't want anyone to mess up your mission critical code, for instance.

    In practice this sort of control is usually done by hand - not many can write changes directly to the official Linux kernel repository, for instance, but the changes are checked by hand by Linus or one of his cohorts. They check that the changes came from whoever claimed to have written them and they usually check the code as well. This is not always possible in product development.

    But in reality, this need came from the fact that some people liked to mess up their Git settings (name & email) so that it was impossible to find out who had done what and this is something you need to know once you detect bugs or other problems in product development.

  3. Let's use an example.

    Let's assume your company has an open-source project and a public repository for it where the latest version provided by you can be fetched.

    If you don't have access control like this then anyone who finds out the name & email address of one of your employees could push malicious code to your official repository probably making massive damage to your company's reputation.