Ran into an interesting issue with User ID impersonation:
Our team member was having access issues, while pushing into one of the GitLab projects. He did not realize that ‘master’ branch was protected.
While trying to reproduce his problem, I used the ‘git config –global user.[name,email]’ commands to change my user.name and user.email to his. I was thinking that GitLab would deny my attempt to push to master. To my surprise it didn’t, but reported that he was the one that performed the commit in the commits tab and in the Files/History.
As a matter of fact, the only place it showed up as my Push, was in the Project/Activity tab, but by now it was someplace at the bottom of a long list, hard to find.
I guess this is a side effect of differentiating between Git authors and Git pushers/committers. My question is: is there a way to force GitLab to display the pusher’s ID in File/History and Commits log, instead of the author's ID that may be recorded in the User’s local Git repo. In other words, I’d rather not see commits made by “Mickey Mouse” or “Cinderella” if that’s what they decide to call themselves on their local repos.
The Git repos on GitLab don’t have information on who pushed the commits. The file/history page and commits log run git commands to populate the page, and the pusher just isn’t available in that information.
What your committers call themselves in their own repos will come across in the commits. As long as they include the emails as one of the emails on their GitLab user profile, their GitLab user profile username should be what is shown most places in the GitLab UI.
For impersonation, that is a problem, but not as big as you might be thinking. GitLab is concerned about who is allowed to push to a repo/branch. Not who the committers are that make up that work. In your case it would have either asked for your username password, or used the ssh key to determine who you were, and that you were authorized to push.
Where impersonation comes more into play is when there neesd to be a level of trust between the pusher (which may be automated) and the committers, for something like a merge request. For this git provides a way to sign commits. GitLab doesn’t currently do anything special with signed commits. But here is the feature request for it:
in that case, what is a recommended approach to maintain some sort of audit of who does what. we have 120 developers with practically equal access to all repos. And as long as everyone is acting professional, there are no issues, but what if someone decide to push something malicious, and it’s not discovered until a few days later in some test. How do we know who did it if GitLab ‘blames’ someone else who knows nothing about it? or am i missing some key point here?
No you are quite right. The committer may not have been the one to push it to that branch. And other than scrolling through days of activity, I’m not sure what you would do.
Being able to search activity would help, but the events table will only store the first 20 commits of any push event, so even then it would have to be a fairly custom smart search to know that the commit you are looking for was part of a particular event.
hm… thank you for the reply - i really appreciate it… albeit i’m not sure how our security folks are going to react to this bit of information
I’m still confused though: GitLab obviously requires my userid/password (or SSH key) to know that i’m the one doing the push, so why can’t it use that information to mark it in its metadata/DB and display that to me on the UI, instead of something unreliable that may come from someone’s local repo ? It seems to me like a basic functionality of any Version Control System, stressing the ‘control’ part here…
It is possible to store the git data, even it git. Some people create git notes during the post-receive hook to store this information. Pulling it back out might be unreasonable to do during a listing page, but the commit page itself could probably show it. You could open a feature request for it.
In the meantime, you could use the pre-receive hooks to prevent anyone other than the gitlab git user from pushing to protected branches, and then require all your devs to use merge request to get their code into the protected branches. The merge would be credited to the merger, which would be the one to blame.
