How can an administrator manually confirm/verify a user's linked email address?

How to Use GitLab Self-managed
1

Hi,

by mistake a user has done lots(!) of commits using a mistyped email
address (git commit --author="NAME <wrong.em@il.address>"). He has now
added the wrong email address to the list of his linked email addresses,
but since this is a wrong and not existing (even technically invalid)
email address, he cannot verify it.

Can I (and how) as GitLab administrator (self-hosted Omnibus
installation, version 12.8.1-ce.0 on Debian Linux) manually set this
linked email address to a confirmed/verified state?

2

I withdraw the question as not being relevant for us any more: I had assumed that GitLab links email adresses in commits only to verified email adresses. However the user is already correctly displayed in the commit history, even though the erroneous email address is still unverified. I therefore don’t need to verify the email address manually.

3

Hi, no, but you can do something to ensure that a particular person has actually done a commit. I’ll give an example.

I can edit my .gitconfig file and in the email field put whatever email I like - an incorrect one, or even an email of my colleague. I can then push that commit, and the incorrect email will show on that commit, or for example the email of my colleague, and people would think that my colleague did the commit when it was actually me. Now obviously that is not good, because I could make it look like my colleague made a really bad commit.

So, to protect against that, it’s best to use GPG keys, and so in my .gitconfig I have:

[user]
	email = firstname.surname@mydomain.com
	name = Ian Walker
	signingkey = my-gpg-signing-key
[push]
	default = current
[commit]
	gpgsign = true

every commit from there on will automatically be GPG signed. Of course, it will only show as verified in the web interface for Gitlab if the email matches the email address tied to the GPG key.

image

As you can see above my commits have verified when being GPG signed and if not, then the space is blank. This link will show how to set it up: Signing commits with GPG | GitLab

4

Thanks @iwalker, that’s very useful hint indeed. In the concrete case there were only four persons having write access to the repository :-). But we might set up gpg signing as a generally recommended policy in the future for all users of our GitLab instance.

1 Like