Home/ Questions/Q 8487223
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-10T21:10:37+00:00

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

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0