" Some user accounts have email addresses that differ only by case" warning, but none found

We have some users in the database that use "originalname+alias@domain.org" email formats. How is this handled after the recent case sensitivity cases?

Could this trigger the warning we see, or is something else also going on here?

I also had the warning on the status report page but the query on the drupal.org help page didn't find anything. However, I managed to figure out there are 2 users whose email address is NULL. Another one of them is the anonymous user.

@klemendev -> you can also check if you have some users with NULL as their email address, for example like this:
SELECT uid, name, mail, status FROM users_field_data WHERE mail IS NULL;
As far as I know, normally the + symbol in email addresses shouldn't cause problems in a MySQL database.

I haven't looked into how exactly the warning on the status report page appears and how it tries to find those users with duplicate emails. Maybe it would need some tweaking.

It was exactly that, users with email null. I am not sure how this can happen that user has null email, but removing those entries fixed the problem.

Thanks for reporting this.

https://git.drupalcode.org/project/drupal/-/blob/11.0.9/core/modules/use...

$query = \Drupal::database()->select('users_field_data');
$query->addExpression('LOWER(mail)', 'lower_mail');
$query->groupBy('lower_mail');
$query->having('COUNT(uid) > :matches', [':matches' => 1]);
$conflicts = $query->countQuery()->execute()->fetchField();

if ($conflicts > 0) {

..is how user_requirements() detects problems.

Looks like we should add a condition to exclude rows where mail is empty / null?

Anyone want to spin up an MR?

This may be as simple as adding:

$query->isNotNull('mail');

Ideally we'd add tests to prove the fix.

However, looks like tests have not been committed from the private security issue yet. Perhaps we could do that early in this case (tests that accompany security fixes are often not added for a few weeks to avoid disclosing details of potential attacks, but that doesn't really seem to apply here).