There is an API which allows you to look up deleted files by hash:
https://commons.wikimedia.org/w/api.php?action=query&list=filearchive&fasha1base36=eu7dlnl8z4upc36048um3aonw45w510&faprop=sha1
https://commons.wikimedia.org/w/api.php?action=query&list=filearchive&fasha1=7f08c97431182ef389ef6f09faac9ff6410b5674&faprop=sha1

It is trying to purge objects created more than 2592000 seconds ago (30 days), with a sleep of 0,0005 seconds between each batch.

I'm also ok with that.

The actual wordlist was published by Tim many years ago,¹ which is much more relevant for an attacker than the blacklist. Someone even created a greasemonkey to check if you were providing a valid captcha solution.

The repo has a tiny blocklist (510 bytes). A 5KB blocklist seems perfectly acceptable to store there, and a good blocklist would benefit everyone.
Do we know the source of that blocklist?
(also, what's the last-modified timestamp of the wmf blocklist?)

nazi is on the blacklist present in the repository since 2014, see 1e5bd7dc3c1be

Titleblacklist, spamblacklist and antispoof use data from public wiki pages.
One could manually parse the wikitext, extract the regex and apply them locally.

That Čeština screenshot shows it is wrongly sorting all Discussion pages together (Diskuse*) rather than using pairs of namespace/talk as stated in the description.

I don't think any certificate could. The SNI is transferred before the certificate is presented by the server. The server can of course be configured not to negotiate any TLS version less than 1.3 However note that in the event that your browser can't support TLS v1.3, you won't be able to view the page at all (regardless of the GFW blocking it or not).

Easy: https://gl.wikipedia.org/wiki/Wikipedia:Wikiproxecto_1000_artigos_de_calidade_para_alumnado_de_12_a_16_anos/Matem%C3%A1ticas?withJS=MediaWiki:Gadget-ArticleQuality.js ☺

In T213655#4880685, @jcrespo wrote:

Could you try to restore it @Platonides using the wiki admin tools before trying some SQL?

It's probably on esams varnish cache but not on codfw.

We already run a wiki for our chapter (well, actually a couple, one public and another private).

To clarify a little that last comment, WMES uses a commercial dedicated server, on which the different services then run on separate containers. The hardware is owned by a third-party (Hetzner), and hosted on their DC. No third party has access to the data contained therein. Even if some of their employees tried to steal something from there by abusing having physical access to the machine, it would be far from trivial.

MarcoAurelio: https://toolsadmin.wikimedia.org/ is part of production services.

If $SECURITY_THEATER is needed for $RIGHT, then the software should not allow $RIGHT actions unless that is in use.

You don't even need to write a 0.

This should be a list of rights that require having been authenticated less than <configurable> minutes ago, which would allow us to change which rights need an "elevated security". We should also allow configuring the suitable providers, so an account could login and edit without 2FA, need a TOTP token for a CheckUser, and creating a sysop would require using the hardware token that is stored in the dungeon safe, watched by lots of guards and crocodiles.

Setting the same cookie many times it should only be stored (and sent to the server) once. If the clients are using a naive approach where they append several values for the same cookie name, it is a client bug.

(starting again to present the code)

@Joe Did you actually read the code?

Well, I don't think it even needs to be treated in a private task. There was a situation about how to interpret the rules / how much pure we wish to be, so people brought it up and discussed it to reach a consensus.

I see some benefit in storing multiple email addresses per account (and if there are several validated emails, the source one could be selectable at Special:EmailUser), but mainly for the case when an email is no longer available.

If you simply remove any html tags and unescape html entities, it is in unified diff format.

@Joe: That's not a problem. Actually, not using local storage is actually easier. It will simply be fetching everything. I still think a cache should be available for who want it. In my tests, fetching from the internet makes it ~1.4s slower, but should be no problem on the same dc.

Ok, I have been preparing the mentioned poc. Should I directly request a new extension repository for it?
As for the associated storage requirements, they easily go down to 9GB. We should decide if we prefer using 256 files of 37M, or 64K files of ~140K each.
(we could as well work with 1048576 text files of ~18K, but that would go up to 20GB!)

Sorry, I was thinking the download link was providing split files like those used in the k-anonymization api (eg. https://api.pwnedpasswords.com/range/7110e), not a big 22GB file but 16⁵ files of about 22KB each.

What's the benefit of having a service for this? These are just static files.

Rather than simply download a json to the user, I think we should provide a .zip file with one folder per wiki.

Well, requiring 2FA just for making JS edits seems a solution more suited to the problem. I was reporting that it was being to tackled that other way. Sorry if I was a bit ranty.

For what is worth, someone at WMF seems to have decided to start enforcing 2FA for this. Last week, WMFOffice started mailing that 2FA MUST be enabled, and threatening with removing administrator access after November 24th.

The php error itself could be solved by simply adding a __toString() method to the IBAN class.

I mentioned it here as the description said that the goal was that the legitimate account owner would notice, but you are right. Split to T210075

1.26 has been EOLed for two years now. Not to mention that the single sign-on requisite means this would only have affected a tiny fraction of installs. Closing and publishing.

At minimum, there must be a throttle for ChangeEmail. Perhaps restrict it to 1 change every 5 minutes, which should be enough for any reasonable use. Then further restrict it if already done more than eg. 10 times.

It should also trigger a flow and email notification to the user that his 2FA has been disabled.

I can think that this would be a problem if Special:ListUsers was itself restricted (using Extension:Lockdown), perhaps because usernames are considered Personal Identifiable Information.

IMHO at least the license issue and the logo image would have to be fixed before.

I have reduced the template text to this failing wikitext:

This exception was added at abd3c02d0811.

I don't think it should report any block if no pages are selected. It should report an error instead. Magically making "blocking from no pages" mean that they can't do an undefined "something else" upload, move, use certain Special page...?) is a bad idea. If we want to disable upload, the revoked rights should be explicitly stated somwhere.

Worth asking the community to be sure, but I think it could fit.

A crazy idea was to use Wikidata entities, but wikitech doesn't have Wikibase Client.

ie. namespaceDupes.php

All of these seem things to be fixed (made parametrizable) at TitlesMultiselectWidget level.

I also agree that T203171 would be more important than admin actions not functioning completely in such case.

Can the people that uploaded designs mention under which license can their stickers be used (eg. Creative Commons Attribution 4.0)?
You can choose Edit Comment at the dropdown menu for when you added it.

Usually I would leave the old values in place, so that things linking to the old content don't break. But in this case, I don't see how it could be useful to link to a stopped RSS feed, so actually replacing would be fine, too.

It is to be added, where it had the https://blog.wikimedia.org url, which is the old blog.

Removing the second image per prtksxna request. bawolff also agreed it seemingly was duplicated.

If a user needs to be blocked, does it really merit the amount of trust that is needed for holding the CheckUser privilege?

While we review all the messages with the new UI, it seems appropriate to also use the opportunity to evangelize about password managers...

(note: they are pages 13 and 67 are according to the internal document numbering, add 10 pages for the absolute page in the pdf)

If each user is given a different public IP, there shouldn't be throttling problems...

Looking at the University of Maryland page (which is 21 years old!), and the mention of eight character passwords, they talk a limit of 8-character in the passwords, which is clearly because of the old DES-based crypt(3):

Currently, the maximum password length on many Unix systems is eight characters, but if you want to add a few more characters to make it easier to remember, go ahead. Just bear in mind that anything after the eighth character will be ignored.

Would love to see some papers on that area.
The links on that section are 10 years old ☹

I would also add a check for the HIBP Pwned Passwords blacklist.

Is there a reason to for increasing the pwlength for new accounts only to 8 ?

Assigned, @Aklapper

@Aklapper: yes.

I can reproduce it with the version downloaded from wikipedia:

As mentioned on irc, this text corresponds to https://es.wikipedia.org/wiki/Usuario:Danielalfredo/Taller (however, it parses fine ☹)

Hmm, reviewing that the READMEs are right and updating these little bits would do a nice GCI task.

Not sure about including it in the emails by default, but seems sensible that it _can_ be included, and it would be easy to create a patch that allows that.