13

Experimenting with git, I've setup Gitlab for a self hosted repository and it looks great.

The one thing bugging me is that it appears anyone can make commits as anyone else (ie: spoof a commit).

ie: I have my users setup in Gitlab with public key access

  • User1
  • User2

Now only those users may push - using their private SSH keys - but it seems there is nothing stopping User2 tweaking their gitconfig to commit under the name of User1 and pushing that up?

The history in gitlab and git -show shows the committer as whatever the User1's gitconfig text was. I want Gitlab to stamp the username associated with the pushing ssh key into the history instead so I know whose ssh key was used to push.

The scenario is the repo would be used in a team environment and it just seems prudent to not allow spoofed commits.

I've done some reading and understand that typically one might change the workflow to have a blessed repository and only have trusted committers that can push to that - but at this stage while learning git I want to stay in a more centralised/SVN type workflow.

Is this possible using hooks?

There is a similar question answered for gitosis but even that appears to only enforce the committer is from a range of users which doesn't stop User1 spoofing as User2 - as far as I can tell.

PS: Maybe I am asking the wrong question - is there a way in gitlab to discover which ssh key (and therefore real user) was used to push code into the repo? It doesn't appear so from what I can find.

Community
  • 1
  • 1
fiat
  • 15,501
  • 9
  • 81
  • 103

1 Answers1

5

Update 2015

As this thread mention, GitLab Enterprise has among its git hooks associated to a project a way to control emails:

Go to project settings -> git hooks and check validation of author email.

Any email that doesn't match a known user is rejected.

Original answer (2012)

A partial way to achieve user id control is to make gitolite (which gitlab relies on) reject the push if at least one of the pushed commits isn't committed by the one pushing it.

When you push, you are authenticated (either based on the name of the public key registered by Gitolite, or by another way like an LDAP connection).
You can add a pre-receive hook which will check all the new commits, and look for at least one committed by the right name (ie the id of the user pushing said commits).
See this pre-receive hook as an example.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I tried this and it very nearly works but I get a strange value for $GL_USER. The hook runs but errors with "_remote: no commit found with firstname_lastname_gmail_com_1345598530 as committer name_". I don't know where that last string of numbers came from - some gitlab internal thing? Gitlab don't appear to support anything other than [their web hooks](https://github.com/gitlabhq/gitlabhq/issues/476) so perhaps this won't work for Gitlab? – fiat Aug 22 '12 at 07:14
  • after some more digging, the $GL_USER value of _firstname_lastname_gmail_com_1345598530_ is the identifier column of the 'keys' table in the gitlab database which stores the ssh user keys. It appears to be auto generated and not settable from the UI. – fiat Aug 22 '12 at 07:47
  • @fiat I confirm: `GL_USER` is set with the name of the public key, named by Gitlab that way, and registered by gitolite. – VonC Aug 22 '12 at 08:08