2

I've already set up my git repos with LDAP authentication. Everything works fine except for the fact that Git allows to put just anything as the committer or author name when you commit. I would need Git to put as the commiter and author name the LDAP authenticated user. I don't want to let anyone in my team to put whatever they want.

Currently we're trying Egit (plugin for Eclipse), which demands author and commiter fields. But still I see that the commit commands also allow to just put anything there. So it seems to be a Git feature. Does it have to do with the fact that it is distributed?

In the questions I've read about authenticating with LDAP, no one seems to be bothered by this. At first I thought that the manual Apache setup I made for this (following Q's and A's found here) was the problem, but using Gitblig which leverages this setup a lot, it is the same.

So the question is: Can I commit to GIT repos with the LDAP user as the commiter/author name?

Pedro Otero
  • 324
  • 5
  • 15
  • 1
    Note that `git` is not `svn`. Committing and pushing to one or more remotes (note that the D in DVCS is for distributed, so all remotes are equal) are two different operations, and LDAP is involved only in the second operation. Also note that letting you commit as anything can be regarded as a feature, since when you rebase your teammate's branch you probably *want* to credit him for his contributions. – Tobia Tesan Sep 03 '15 at 22:32
  • 1
    how about signing commits and enforcing commit signatures in a hook ? – Markus Mikkolainen Sep 03 '15 at 22:33
  • @MarkusMikkolainen but still, they could type anything in there and that's what I don't want. I find it hard to believe 'cause it seems that anyone can let a commit untracked by putting in a shady name. I guess distributed is not the way to go for my company. – Pedro Otero Sep 03 '15 at 22:40
  • @TobiaTesan yes, I was thinking that might be the only way. It still amazes me how this behavior of git seems ok, given the fact that I could even course on the author name and no one would be able to identify who really commited. Sometimes you need to know who is responsible for what. As I told in a previous comment, I think this is a no-no for Git regarding the needs of my company. – Pedro Otero Sep 03 '15 at 22:43
  • 2
    @PedroOtero That's *exactly* what signed commits are for. They are cryptographically signed so that they cannot be forged and can be used to authoritatively identify who made a commit. – larsks Sep 03 '15 at 23:53

1 Answers1

2

It still amazes me how this behavior of git seems ok, given the fact that I could even course on the author name and no one would be able to identify who really committed.

It is a natural consequence of a distributed system: a user doesn't have access to a centralized authentication server, so a "marker" (a string representing his/her username) is used for author and committer.

At my company, using gitolite, I put in place a script which check that at least all commits pushed was committed by the user authenticated by LDAP.

gitolite knows the user as $GL_USER, and I check each commits.

That is obviouly not a general solution, as it prevents a user pushing any rebased commits, which include commits from others. But in my particular setup, this workflow worked.

The more general solution remains signing the commits. 

git commit -a -S -m 'signed commit'

Starting git 2.6, the automation of checking signed commit (with git verify-commit) will be easier: see "Verifying signed git commits?"

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • @PedroOtero: don't do this, though. Preventing rebase is in general *not* okay. – Tobia Tesan Sep 04 '15 at 11:39
  • @TobiaTesan I agree, and clearly mentioned in my answer that it was specific to my environment, and not a "general" solution. – VonC Sep 04 '15 at 11:44