2

We host a private gitlab repo, but I believe this is an overall git question since I've seen this behavior before.

Let's say my REAL gitlab / github / etc account details are as follows:

Username: emmdee

User Email: emmdee@my-company.example.com

So I go to some server and clone a repo, make some changes and I'm ready to commit.

If I set the username and email locally: 

git config user.name "Someone Else"
git config user.email "someoneelse@example.com"

When I push a commit into the server, the above username/email is added as the commit author.

The "Someone Else" is shown as the author regardless of the fact that I needed to enter my real credentials to authenticate the push (either ssh key or user/pass).

Problem scenario case:

Team of 30 devs, maybe even some external vendors. Someone pushes some questionable code but has "spoofed" their username/email as shown above. How can I track down the actual author that made the push? (They had to have authenticated during the push action)

Questions:

  • Is there a specific reason for this behavior that I'm not understanding the purpose of?
  • Is there a way to view the original commit author (since they authenticated during the push either with user/pass or ssh key)
  • Is there a way to disable this server-side and enforce real info to be used (or best case - just automatically use the account info used to authenticate the push)
emmdee
  • 1,541
  • 3
  • 25
  • 46
  • 1
    Probably you want the *committer* to be what would be verified, not the author (as there are definitely plenty of situations in which someone may be legitimately pushing commits not authored by them). You may also want to look into [signing commits](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work). – Andrew Marshall Apr 20 '18 at 01:22

2 Answers2

2

Is there a specific reason for this behavior that I'm not understanding the purpose of?

Git is a distributed source control system: it does not have access to a "real userbase referential" common to everywhere you can do a commit: so the user.name/email are just string that you setup.

As such, the authentication part (when pushing for instance) has nothing to do with the commit authorship part.

If you have "spoofing" concern, then you can at least enforce accepting only signed commits (see "Is there a way to “autosign” commits in Git with a GPG key?"): that would associate to the commit an information which proves its origin.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • still don't understand this fully, when pushing to a remote server, gitlab/github etc there is a authentifcated user, those remote server can reject push if commit email is not belong to that authentifcated user – WestFarmer Oct 28 '21 at 01:35
  • @WestFarmer The question is about commit *authorship*, not about remote Git hosting server *authentication*. To my knowledge, you can push any commit authored with any email: they won't get "rejected". – VonC Oct 28 '21 at 05:21
1

You should sign your commits with your GPG key. This way, people can trust that only you can have made a specific commit, provided they trust your public key.

In your case, you can have everyone create a pair of GPG keys with their real information (name + email), and you make sure that your get their public key securely. You can then verify their commits using their public key.

Guillaume
  • 1,814
  • 1
  • 13
  • 29