We should probably reject such registration on wikitech where it is easy to provide a non-useless error message.

In T270233#6694081, @Tgr wrote:

We should probably reject such registration on wikitech where it is easy to provide a non-useless error message.

You would also need to enforce this in Striker, and any future replacement for Wikitech & Striker for Developer account provisioning (T179463).

Thanks for fixing the task description, clearly I was half asleep.

@bd808 is a wikitech fix worth it separately or should it be fixed everywhere at the same time? I can provide a patch for MediaWiki, no idea how to do it with Striker though.
(I wonder if it made sense to centralize things by having Striker use action=createaccount?)

I'm not sure that preventing duplicate emails in the LDAP directory is actually valuable at all. It seems more like an implementation quirk of the external account linkage in Gerrit that it is using a non-unique lookup token than a bug in the Developer account system itself. The backing LDAP directory enforces unique values for uid (shell user name) and cn (Wikitech user name). It really feels like Gerrit linkage should be based on one or the other of these and not mail which is non-unique.

Searching the LDAP directory for duplicate emails is a bit annoying, but it is pretty easy to make a check in Wikitech's db of attached Developer accounts for duplicate emails. At the moment select count(*) as dups, user_email from user group by user_email having dups > 1 order by dups asc; returns 912 rows with duplication counts ranging from 2 to 250. The vast majority of these are duplicate count == 2.

If we block email duplication going forward, do we also need some kind of historic cleanup? What do we do for folks who want/need bot accounts that they do not intend to use with Gerrit?

Gerrit does the mapping between its internal account and the LDAP account using the LDAP cn field normalized to lower case. The email is not involved there.

However since Gerrit 2.16, uniqueness of emails across accounts is enforced. Apparently it caused troubles with some external authentication system which might use an email as the id key. https://gerrit-review.googlesource.com/c/gerrit/+/169970 . The commit states that duplicate email would not cause any trouble when the external id is not an email (such as LDAP with cn) but there is no feature flag to disable the uniqueness enforcement.

For the wiki bot accounts, I guess one can use an email alias by appending to their mailbox name an extra string prefixed by + (ex: jane+wikitechbot@example.org get delivered to jane mailbox). Not all email providers support that, but the large majority probably do (gmail definitely does). That might be a good enough workaround.

In T270233#6697881, @hashar wrote:

For the wiki bot accounts, I guess one can use an email alias by appending to their mailbox name an extra string prefixed by + (ex: jane+wikitechbot@example.org get delivered to jane mailbox). Not all email providers support that, but the large majority probably do (gmail definitely does). That might be a good enough workaround.

Sure, requiring unique email addresses is not a problematic limitation. Having to figure out from a completely generic error message what is going on is a waste of time though.

In T270233#9494689, @hashar wrote:

Declining since the root cause was two accounts having the same email addresses while Gerrit requires accounts to have a unique address.

That feels more like a restating of the bug description than an explanation of why it should be declined.

In T270233#9497614, @hashar wrote:

My guess is for us to enforce the email uniqueness on the Wikitech side

I agree that would make the most sense, except it's not exactly Wikitech anymore (which has signup disabled), it would have to be done in idm.wikimedia.org I think.

Per Gergo, lets requalify from wikitech.wikimedia.org to Bitu

Infrastructure-Foundations : this task is to enforce uniqueness of emails since that is used by Gerrit as a unique identifier. If one reuses an existing email, the new account would not work in Gerrit which causes some confusion. It is not happening often though thanks fully, but anytime it does, that is a bit confusing for everyone.

In T270233#9501146, @hashar wrote:

Per Gergo, lets requalify from wikitech.wikimedia.org to Bitu

Infrastructure-Foundations : this task is to enforce uniqueness of emails since that is used by Gerrit as a unique identifier. If one reuses an existing email, the new account would not work in Gerrit which causes some confusion. It is not happening often though thanks fully, but anytime it does, that is a bit confusing for everyone.

As I said in T270233#6696661, I don't think that we should have to add new requirements to Developer accounts because of a poor integration with Gerrit. There are actually quite a few Developer accounts that share email addresses in the existing directory. Not everyone uses Gerrit, and if https://www.mediawiki.org/wiki/GitLab/Roadmap is to be believed someday nobody will.

According to T317218 GitLab also rejects duplicate email addresses. Allowing people to sign up with an account that then won't work is a very sub-par user experience, wastes the time of volunteer developers, and also wastes the time of people with whom the bug reports about Gerrit not working end up.

In T270233#6696661, @bd808 wrote:

If we block email duplication going forward, do we also need some kind of historic cleanup?

I don't think it's worth it, sounds much more complicated than just rejecting during signup, most of them are probably inactive, and for the rest presumably not being able to use Gerrit is not a problem, otherwise they would have fixed their email address already.

What do we do for folks who want/need bot accounts that they do not intend to use with Gerrit?

They will have to spend an extra second or two on adding +bot to their email address.

@Tgr do we want to do any more work on this task? If not I'll go a head and close it.

I am in favor of enforcing uniqueness of email addresses at account creation. While this may be a slight annoyance during account creation, it prevents accounts from being unusable in either Gerrit or GitLab, which could be a greater inconvenience for users of those applications.

Both Gerrit (this task) and GitLab (T317218) require that email addresses be unique across accounts. Anytime someone creates an alternate account, they face the same issue: the account can be created but is unusable in either Gerrit or GitLab. If we want to enforce this uniqueness at account creation, some work will be needed in Bitu. When an email is already known, we should prevent account creation and advises users to use a different email, tipping them on using an alternative email, potentially viaemail aliases (e.g., by suffixing the first part of an email with + followed by a string, as in john+alias@example.org).

However, enforcing uniqueness might cause friction for some developer accounts. It’s uncertain how many people would be affected compared to those who face issues with Gerrit or GitLab account creation. Additionally, we might need to deal with existing accounts sharing the same email. For Gerrit, such accounts do not exist, as it refuses to create local accounts under those circumstances.

In earlier discussions, @bd808 mentioned uniqueness would add an extra restraint on developer accounts. Notably, these accounts are not necessarily used on Gerrit or GitLab, meaning they are not affected by reusing an email.

If we maintain the status quo and allow duplicate addresses, users will still file tasks about being unable to log in which arguably is more steps than having to switch to an email alias.

It is left undecided for now.

Yeah I'd also enforce it at the actual point of signup.
This would be less annoying if Gerrit just told people that something is wrong with their email address, but (at least as of 2020) the error message was really unhelpful.