There is no need to actually proxy gravatar. We could have our own instance. Gravatar is just a service mapping email md5 to an uploaded image. Is people still uploading their avatars there? Didn't that stop like a decade ago? Even if some people have an image there, it seems saner to use our own "wikimedia avatars". I'm not particularly happy on using the (hashed) email as primary key, but that seems to be what they are working with.

It could go both ways. If as an Hungarian with only Hungarian credit card, and temporarily visiting the US, you are given HU options, it would succeed. OTOH, if you only had a US card, or if it persisted a US cookie after coming back, it's a failure.

Files uploaded in 2013 with two upload entries at the same minute.

The content encoding of 'identity', was added in rfc2616 with a note that it "SHOULD NOT be used in the Content-Encoding header". The transfer coding identity was removed by rfc7230. rfc7231 uses "identity" as a special value in the context of Accept-Encoding, not of Content-Encoding. Anyway, the semantics of a Content-encoding: identity are completely clear and supported even if it may make for a redundant header.

$maxConcurrency was set to 50, but we had nearly one thousand operations pending.

I can disable $async on FileBackendStore::doQuickOperationsInternal(), and then it no longer fails. Understandably, that makes the process slower (Copied 969 captchas to storage in 43.6 seconds).

I found it is a file descriptor problem. ulimit -n is set to 1024. FormatJson is failing with

I would try

• throwing a clearstatcache() somewhere, in case it makes find the file Json again
• run a different program than python that creates the file externally, e.g. touch filename

It doesn't make any sense that you can upload to phabricator, but not to commons.
I would suspect some crazy with some intermediate box, but the whole connection is encrypted.

Note: The receiving Exim doesn't seem to be configured to accept list mail:

MX records cannot have IP addresses. They must be associated to a hostname (plus a priority)

It might be a simple issue of changing the db charset, or adding a SET NAMES to the client.

Maybe, rather than a new permission for that, something like $wgCustomModelProtection[] which allows requiring a specific right for certain models (presumably those that could be sensitive, most models shouldn't need that), rather than a one-right fits all approach.

Heh, calling it "Welcome Bot" sounded nicer, even if it would still be saying go away from GitHub ;)

I understand the app Name will be the bot name, so rather than "Wikimedia PR Closer" I would prefer something more user-friendly, such as "Wikimedia Welcome Bot for GitHub users"

A point that is somewhat behind this is that the edit conflict isn't isn't too user friendly, which makes edit conflicts more burdensome.

https://github.com/WICG/trust-token-api seems to be another project doing basically the same thing.

If a third party would be presenting our challenges, it could help making them not be able to link the requestors of captchas (for which they would have IP addresses, run js, etc.) and the actual wikipedia (since the token will be redeemed at a later date).

Yes, because with the behavior of the "back" button in browsers at the time, it was actually needed. It no longer is.

Note that MediaWiki doesn't "fail" to detect the conflict if the edit was made by the same user. It explicitly goes and does an expensive check to see if it should ignore the conflict because the edit is by the same user. This was explicitly implemented as a feature. Don't ask me why though ;)

I don't think that graph is the right one, André. It may provide approximate data (both are emails), but I think list email is even sent from a completely different relay.

I think it could be a good request that the tool shouldn't show it. However, the tool is completely right. The user was blocked for 1030 days.

Why are you using that query?

And how do you know, server-side, the number of px in 1 em for the current user?

There are file descriptors being opened that you did not capture. Some suggestions: openat, dup2, socket, accept...

A great usecase of this would be to allow showing a collapsed view of the history page. Currently, you have some page histories where it almost hasn't changed for years, yet there are a lot of history entries due to edits and reverts/undos.
It would be great to have them collapsed as a single link mentioning there were 53 irrelevant edits, so that only actual changes affecting the current page are shown.

Or simply a Michael Jackson event! (that we'd better be aware, too)

In T239150#5846411, @jrbs wrote:

(...) Then we can hard-reset your password and reset it through the system.

Alternatively you can email ca-at-wikimedia.org from the email associated with the account.

@Beej--phabricator can you check if the password being rejected was indeed in the large list at
https://github.com/danielmiessler/SecLists/blob/aad07ff/Passwords/10_million_password_list_top_100000.txt ?

Maybe mwlog1001 will have some details about what happened?

As an external solution, it could be added to an external mailing list archiver such as marc (they already have wikitech-l, mediawiki-l...)

It was added by @chasemp on Apr 23 2019, 6:53 PM, along WDoranWMF.

The entry SBL205747 is special in that it is an entry requested by mail.com itself. When they consider that the email they are going to send is spam, they send it through an IP address listed there so that people checking the Spamhaus blacklist may block it.

Then the internal urls are really no different than the public ones. Converting them would simply mean prepending "https://upload.wikimedia.org/wikipedia/commons/thumb/"

How are the internal swift urls? I'm not sure why we need two lists.
Also, while a baseline, I don't expect python to be the most efficient construct. A better one could be construed directly in C. Or even use a Bloom filter rather than a set.

I think the bzip2 api doesn't handle the multistream transparently, so tools coded using that would probably be affected.

The error "page" is actually https://office.wikimedia.org/wiki/Main_Page#/media/File:Wikimedia_Foundation_All_Hands_2018_-_Myleen_Hollero_(edited).jpg, which is failing due to the underlying https://office.wikimedia.org/w/api.php?action=query&format=json&prop=imageinfo&titles=File%3AWikimedia_Foundation_All_Hands_2018_-_Myleen_Hollero_(edited)%2Ejpg&iiprop=url&iiurlwidth=1024&smaxage=86400&maxage=86400 erroring with:
code: readapidenied
info: You need read permission to use this module.

I can help mentoring these @Gopavasanth

The file was reuploaded by Denniss on September 2016, but the original file is still missing, TheSandDoctor.

(old comment that was waiting as draft in the browser)

I'm not sure about the purges. Sometimes you need a null edit in order to really bypass some caches.

Looks like a partially downloaded image. Probably an interrupted download produced a truncated image that was then cached (locally, on a server?).

For one, when reading the UI of T234537#5553996, initially thought that "Require email address" meant requiring being in control of the email address (i.e. that the feature was like requiring that the user validates the change via email in addition of knowing the current password before password changes take action), whereas it actually is meant to require knowing which is the email address linked to the account.

As an alternative solution, you could add an AbuseFIlter that prevents non-admins from adding {{yes}}

The default value of stablepages is 'exclude', since the very beginning (f798ae02d418f63301da636d1d21719ead743773).

Similarly, on Wednesday ...@yahoo.com subscriptions were disabled for wikitech-l due to this same issue, bouncing https://lists.wikimedia.org/pipermail/wikitech-l/2019-September/092531.html, a legitimate email which seems perfectly innocuous.

See T22507 for the same issue in 2009

Yesterday, we had the same issue on biblio-es-l with all subscribers using a yahoo.es email address being automatically disabled delivery (funnily, it was not the case for those with a yahoo.com one), as the max retry timeout for emails from an email from Tuesday was reached.

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.

I think that rather than loading the main page, and get confused when it's a special page, it should not attempt to use that as a title.

@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!)