In T64718#3503249, @Cavila wrote:

+ !

I'm not sure how much discussion we still need. For a smooth transition, I'd say: if the toolbar is enabled, show it to all users by default (current situation) and offer a config setting to tie its visibility to specific user rights.

I withdraw this request.

@Tgr I'm not much familiar with SQL. Is SELECT * FROM user WHERE user_email COLLATE utf8_unicode_ci = '<email>'; work without problem? Adding new index that based on function such as CREATE INDEX user_email_lowercase on user(lower(user_email)); is not supported in MySQL. Adding a new field that stores lowercased email addresses could be one way to solve it but I think it might be too overkill.

In T30085#1713635, @Tgr wrote:

We store authenticated and pending addresses in the same DB field so the implementation would have to be careful, but a DoS of the of the email authentication is certainly avoidable. Not though that email verification is a configuration flag and theoretically there can be wikis not using it (in which case email login should probably just be disallowed altogether).

@Tgr Then keeping old email addresses as same as now and only saving new email addresses as lowercase would be ideal?

In T30085#1700247, @Ricordisamoa wrote:

https://lists.wikimedia.org/pipermail/wikitech-l/2015-February/080981.html

I'd like to get comments about normalising email addresses. A current implementation will turn every email addresses in the user table into equivalent lowercase characters, and will also save new email addresses in lowercase.

In T30085#1692382, @Qgil wrote:

"We cannot log you in because this email address is being claimed by more than one Wikimedia account. You can log in using your username, and you can change your email address in your Preferences."

@RobLa-WMF yes. It would be okay to me.

@tstarling I'm afraid I'm not able at every Wednesday 21 o'clock UTC. On Wednesday, I'm able to meet at after midnight or before 14 o'clock in UTC.

Account selector can be one solution for email address duplication, but it still requires us to deal with time attacks and may result in longer login processing time for all users. I believe there is no way to prevent time attacks completely. We have to choose between security and convenience.

Arch Linux users are also affected. They use 7.1 currently.

Finally, 7-year-old child bug has been fixed.

Any progress on this issue?

@aude Okay. That's a problem. Can you change the description and title of the issue to match with current circumstances?

In T90438#1216562, @aude wrote:

@devunt I know to run composer install, but the problem is the error information isn't very friendly and shouldn't come with a stack trace :)

In T15712#1204581, @greg wrote:

Let's get this extension deployed to the Beta Cluster and tested there before going to production; doesn't need to be for terribly long, just sanity checking.

Josa extension had finished its security review.

I'm interested at this project and I'm willing to apply GSoC as a candidate with this. Anyway, and unfortunately, I don't have a much experience with CodeSniffer. But I have a some experience with MediaWiki code conventions, creating some testsuite in other languages (like python's unittest) and modifying existing linters (flake8/scss linters etc). Am I suitable for this project?

@Qgil Is there any plan to make this as a GSoC project?

Have you installed the all external vendor libraries and kept it up-to-date?

Closing 6 year olds bug finally.

@Qgil I'll upload a new patch soon. And current priority seems correct.