And this, of course, is not a duplicate of T59264.

In T229823#5393033, @Aklapper wrote:

This sounds like a duplicate of T43338?

“paragraphs, categories, templates…” – no way, Ī̲ don’t propose to fit MediaWiki with AI. Only several checks based on a dumb (sub)section tree-like model of the page.

How certain is that the attack—if it was noticeable at all—was the root cause of the esams outage? My analysis of Grafana plots and personal experience led to following conclusions:

It is pointless to discuss these Phase IVIVIVI in detail before consensus on how namely may IPs be encrypted, and whether they should be at all. If the address encryption is expected to pulverize each /64 IPv6 block—leaving the end user without an option to see all edits from the same 2hhh:hhhh:hhhh:hhhh: (with possible differences in the lowest 64 bits)—then the proposal should be dismissed and a homework of learning actual IP-editing practices has to be assigned to the author.

Thanks for a prompt reply, but the way PdfHandler treats this error is disrespectful. Can a sensible error message be generated, please?

Second this – noted the sudden change on https://commons.wikimedia.org/wiki/File:FlowRoot_and_flowRegion.svg . Moreover, when I purged https://upload.wikimedia.org/wikipedia/commons/thumb/3/35/Bayesian_Calculus_Summary.svg/1051px-Bayesian_Calculus_Summary.svg.png , black billets disappeared (were present in the cached version). Does this new rsvg making {{SVG 1.2}} obsolete?

… because the Phabricator application relays mail having no Message-ID header of its own to a local Exim MTA. Unlikely Exim would replace an existing ID with crap. IMHO not a good practice, to send Emails lacking Message-ID.

P.S. the same should be done for DjVu (which AFAIK lies in the MediaWiki core) and perhaps for TIFF as well.

In T38597#5081261, @TheDJ wrote:

Problems of having to regenerate thousands of images guaranteed not to be a scalability issue ?

For a huge site like Wikimedia? Some thousands (or even myriads) of gs(1) invocations? Insignificant.

In T38597#5080252, @TheDJ wrote:

There is no obstruction, just status quo and lots of other things to work

The only “work” to do was to change the value of [[ https://www.mediawiki.org/wiki/Extension:PdfHandler#Configuration | $wgPdfOutputExtension ]] from jpg to png – in this case, perhaps, noone would remember about the possibility of PDF → JPEG transformation, as PNG is universally supported in browsers since c. 1998, and no “huge impact on wikisource” would ever occur but disappearance of dirt. Instead, certain users opted to argue about “wide-color images”, increasing JPEG quality from 75% to 95%… how often do Wikimedians wrap color photography or painting into PDF?

Ī̲ don’t expect admins to proceed with the desired change in any foreseeable future, but fortunately a simple DHTML tweak can bring PNGs – see https://meta.wikimedia.org/wiki/User:Incnis_Mrsi/PDF-PNG.js

In the context of Unicode discussions “characters” is an ill-advised term because some code points—such as U+FFFE—are explicitly defined as “non-characters” .

Found this crap myself trying to feed an interwiki prefix to importScript – see https://commons.wikimedia.org/wiki/File:Cross-site_importScript_resulted_in_HTTP_403.png

So?
Where is that JPEG lover among Wikimedia techs who obstructs fixing the bug for 4 years?
Look at https://commons.wikimedia.org/w/index.php?title=File%3AResourceLoader_Wikimania_2011.pdf&page=3 for example – several respected guys have their produce presented on par with miscellaneous rubbish from Wikimedia Commons, excretions of such users of Microsoft Paint or Adobe Photoshop who know nothing about formats.

The most suspicious development in this story is that these are Wikimedia users—some not even sysops on any wiki where a revision is missing—try to trace causes of the bug, whereas all people having shell access to Wikimedia servers are silent. Are files really missing from directories or only unreadable for some reason (permissions, file-system damage, I/O error… )? For files which are missing, how recently did they exist in the past? Which procedures (such as moving files from one storage to another) could potentially cause the data loss?

Of course, it isn’t my job to make bot edits manually. Nor anybody here should hire professional engineers at own expense, and Ī̲’m astonished that such sophistry is encouraged here. At the end, Ī̲ could manage such software myself, but it is full of PHP. Nowadays an Internet dweller may have impression that half of the world is coding PHP – can’t the Wikimedia Labs community co-opt some of these guys for this task?

Can’t “regexes not being escaped properly” be used—at very least—for injection of arbitrary data into the edit? As for Wikimedia stewards, how many of them have necessary access to the Toolforge platform? Of course, any of the stewards can globally lock the account of CommonsDelinker, but the bot software could be used—while running—for making harm in other ways.

Not to Steinsplitter – we don’t communicate due to personal reasons. Other Wikimedia Commons guys AFAIK don’t support this software. Moreover, edits by CommonsDelinker threaten all Wikimedia, not Commons specifically.

Oops, from https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29/Archive_167#Transparent_png_files and other discussions this is irrelevant to SVG at all, but something with Web typesetting by MediaWiki. Missed the point.

Sorry, can anybody explain why images from https://commons.wikimedia.org/wiki/Category:Transparent_squares are not affected? Look e. g. at https://upload.wikimedia.org/wikipedia/commons/thumb/0/02/Transparent_square.svg/512px-Transparent_square.svg.png – the SVG⇒PNG conversion occurred today, the PNG wasn’t cached from þe olde goode times, and it is fully transparent. Some essential conditions appear to be missing from description of the bug.

Special:Log for the stuff several months old becomes painfully slow, where remains usable at all. Nowadays it fails with Wikimedia\Rdbms\DBQueryTimeoutError as explained in T180919 instead of a blunt 504, but it is seemingly the only improvement since 2015.

Possibly related.
[WngdQApAME8AABNjd-cAAACR] 2018-02-05 09:01:48: Неустранимое исключение типа «Wikimedia\Rdbms\DBQueryTimeoutError» on https://commons.wikimedia.org/w/index.php?title=Special:Log/JackPotte&offset=20170819222910&limit=500&type=&user=JackPotte
[WngetQpAIC8AACoGlesAAACK] 2018-02-05 09:08:01: Неустранимое исключение типа «Wikimedia\Rdbms\DBQueryTimeoutError» on https://commons.wikimedia.org/w/index.php?title=Special:Log/JackPotte&offset=20170819201205&limit=500&type=&user=JackPotte
(yet another error on the same spot as above, forgot its ID)
[WnglJApAICoAAE-2J0cAAAAO] 2018-02-05 09:35:28: Неустранимое исключение типа «Wikimedia\Rdbms\DBQueryTimeoutError» on https://commons.wikimedia.org/w/index.php?title=Special:Log/JackPotte&offset=20170819195933&limit=320&type=&user=JackPotte
[WngowgpAIC0AAIqzxiAAAACT] 2018-02-05 09:50:55: Fatal exception of type "Wikimedia\Rdbms\DBQueryTimeoutError" on https://commons.wikimedia.org/w/index.php?title=Special:Log/JackPotte&offset=20170819195238&limit=320&type=&user=JackPotte&uselang=en
[WngulwpAAEAAAH@uMrUAAABR] 2018-02-05 10:15:47: Неустранимое исключение типа «Wikimedia\Rdbms\DBQueryTimeoutError» on https://commons.wikimedia.org/w/index.php?title=Special:Log/JackPotte&offset=20170819195238&limit=320&type=&user=JackPotte – exactly the same place as above (without uselang only), and after as much as 25 minutes

Perhelion is right, Wikimedia volunteers shouldn’t spent efforts on compatibility kludges helping Adobe to promulgate their Illustrator and other house products. Better to design a bot fixing such font specification anomalies; it’s this consistent with Wikimedia mission to produce a reusable content, not a kludge envisaged.

In T90475#3612973, @Bawolff wrote:

However given how global user pages currently works - that seems unlikely to happen

Do I understand correctly that, after fulfilling the task, <includeonly>__NOINDEX__</includeonly> will behave intuitively?
With the present software, it has no effect.