Trying with modern librsvg, I get Error rendering SVG Jamaica_Constabulary_Force_emblem_(fair_use)-plain.svg: rendering error: NoMemory. Production librsvg just generates an empty file. Both fail quickly, not waiting on a timeout or anything.

Down again. Would it be possible to return an error other than 404 for this? I have a few (infrequently run) integration tests that use this API, and it would be useful to be able to detect when this happens.

It appears that the new form doesn't switch the radio button to "Get edits" when I accidentally try to get IP addresses for an IP. The old form would show an error and switch to "Get edits", but the new form just shows the error.

The last part of URLs should already be normalized by the upload-frontend proxy, rOPUP modules/varnish/templates/upload-frontend.inc.vcl.erb:155, so there's no affect on server-side caching. I see no reason to error here, though a redirect to the canonical may be appropriate.

If someone with CU (or CU log, in the case of ombuds) access is compromised, we have much larger issues than the IP Info log.

SVG support is still inconsistent, especially in IE 11 (which is still supported on Wikimedia wikis for the moment). SVG is generally smaller, but not always (we have some absurdly large SVG files being mostly used for 220px thumbnails). Making arbitrary user-generated SVGs safe for client-side rendering is not entirely trivial, see T5593: [Epic] SVG client side rendering and subtasks. Further discussion is best placed on one of those tasks.

+1 to removing ipinfo-view-log from sysop no later than Monday morning. I don't think this quite justifies an emergency Sunday change, but I also don't think we need to wait for Legal here.

access was granted to staff and steward in T296499#7962227

It looks like the global group modifications never happened. I have granted ipinfo, ipinfo-view-full, and ipinfo-view-log to staff and steward. T309318 has been created to clarify that global sysops should also be given access.

For what it's worth, the OAuth app guidelines TNT linked are a draft created 5 years ago without significant revision or discussion since. I do think it would be useful to have a discussion between stewards, WMF security, the WMF staffers who already help review OAuth consumers, and the broader community about how these consumers are reviewed, and to work toward consensus-backed guidelines.

https://commons.wikimedia.org/wiki/MediaWiki:Gadget-Stockphoto.js#L-40 tests for skin support, so it's not loaded on New Vector after the variable was changed.

I've noticed this as well. I edited the structured data on https://commons.wikimedia.org/wiki/File:GLASER-DIRKS_100G.jpg with QuickStatements, and everything looked fine. I then edited the wikitext with the normal editor (though it was opened by https://add-information.toolforge.org) and the structured data disappeared. Purging and null editing didn't help, and another editor could see it fine. Only after saving another edit to the same page did it reappear.

But, even if we agree with that, what is sure is that it can not be that a random final user, after one request, get such an error

The actual failure for this thumbnail is

ImageMagickException: Failed to convert image convert: IDAT: invalid distance too far back `/tmp/tmp5SM7vX' @ error/png.c/MagickPNGErrorHandler/1628.

which is easily fixed with pngfix. I have done so, the file is now thumbnailed properly.

429 is returned when the thumbnail hits one of four ratelimits (see https://wikitech.wikimedia.org/wiki/Thumbor#Throttling). That includes a ratelimit on requests for thumbnails that have recently failed to generate. 429 is used because the request should not be retried at that point. This task is largely a duplicate of T175512.

That annotation is added in rEFLR frontend/FlaggedRevsUIHooks.php:789. It looks like if the revision text is deleted, the annotation won't be shown at all, based on rEFLR frontend/FlaggedRevsUIHooks.php:763. Easy fix would be to change that so it isn't shown if any part of the revision is deleted.

The simple solution would be to change securepoll-voter-name-remote from $1 to <nowiki>$1</nowiki>. Or we could change it to a CentralAuth link (unless we run elections from private/fishbowl wikis?). securepoll-voter-name-local should be fine because the username's in a link already.

centralauth-merge-method-admin uses rECAU icons/merged-admin.png, would it make sense to reuse that icon? There's only 2037 accounts with that status, so it's not exactly common (source).

In Wikimedia code, pyexiv2 is only used to read image orientation, exiftool is used for everything else. Thumbor proper uses py3exiv2, but might switch to pyexiv2 (which has its own problems and probably wouldn't be suitable in Wikimedia production).

Historically, for whatever reason, that hasn't been done, and there are several examples of stewards using their own accounts for semi-auto or supervised auto global blocks and locks. I do think it's mostly been an expediency thing, and there's no statement in policy, guidelines, whatever, for or against the practice.

This is necessary mitigation for T265845.

I wouldn't exactly call it a feature. An anti-feature, maybe. It certainly makes things like reading discussions more difficult.

Good to hear, thank you.

I used the RIPEstat Announced Prefixes API, since that's what AntiCompositeBot is set up to use. There are, of course, more and less specific announcements that overlap.

31.13.24.0/21
31.13.64.0/18
31.13.64.0/24
31.13.65.0/24
31.13.66.0/24
31.13.67.0/24
31.13.68.0/24
31.13.69.0/24
31.13.70.0/24
31.13.71.0/24
31.13.72.0/24
31.13.73.0/24
31.13.74.0/24
31.13.75.0/24
31.13.77.0/24
31.13.80.0/24
31.13.81.0/24
31.13.82.0/24
31.13.83.0/24
31.13.84.0/24
31.13.85.0/24
31.13.86.0/24
31.13.88.0/24
31.13.89.0/24
31.13.92.0/24
31.13.93.0/24
31.13.94.0/24
31.13.96.0/19
45.64.40.0/22
66.220.144.0/20
66.220.144.0/21
66.220.152.0/21
69.63.176.0/20
69.63.176.0/21
69.63.184.0/21
69.171.224.0/19
69.171.224.0/20
69.171.240.0/20
69.171.250.0/24
74.119.76.0/22
102.132.96.0/20
102.132.96.0/24
102.132.99.0/24
102.132.100.0/24
102.132.101.0/24
103.4.96.0/22
129.134.0.0/17
129.134.25.0/24
129.134.26.0/24
129.134.27.0/24
129.134.28.0/24
129.134.29.0/24
129.134.30.0/23
129.134.30.0/24
129.134.31.0/24
157.240.0.0/17
157.240.2.0/24
157.240.3.0/24
157.240.6.0/24
157.240.7.0/24
157.240.8.0/24
157.240.9.0/24
157.240.10.0/24
157.240.11.0/24
157.240.12.0/24
157.240.13.0/24
157.240.14.0/24
157.240.15.0/24
157.240.17.0/24
157.240.18.0/24
157.240.19.0/24
157.240.20.0/24
157.240.21.0/24
157.240.22.0/24
157.240.24.0/24
157.240.25.0/24
157.240.26.0/24
157.240.27.0/24
157.240.28.0/24
157.240.30.0/24
157.240.192.0/18
157.240.194.0/24
157.240.195.0/24
157.240.196.0/24
157.240.197.0/24
157.240.199.0/24
157.240.200.0/24
157.240.201.0/24
157.240.203.0/24
157.240.204.0/24
157.240.205.0/24
157.240.206.0/24
157.240.207.0/24
157.240.209.0/24
157.240.210.0/24
157.240.211.0/24
157.240.212.0/24
157.240.213.0/24
157.240.214.0/24
157.240.216.0/24
157.240.217.0/24
157.240.218.0/24
157.240.220.0/24
157.240.221.0/24
157.240.222.0/24
157.240.223.0/24
157.240.224.0/24
157.240.225.0/24
157.240.226.0/24
157.240.229.0/24
157.240.231.0/24
157.240.232.0/24
157.240.233.0/24
157.240.234.0/24
157.240.235.0/24
157.240.236.0/24
157.240.238.0/24
157.240.240.0/24
157.240.241.0/24
173.252.64.0/19
173.252.88.0/21
173.252.96.0/19
179.60.192.0/22
179.60.192.0/24
179.60.193.0/24
179.60.194.0/24
179.60.195.0/24
185.60.216.0/22
185.60.216.0/24
185.60.217.0/24
185.60.218.0/24
185.89.218.0/23
185.89.218.0/24
185.89.219.0/24
204.15.20.0/22

https://salsa.debian.org/debian/imagemagick/-/blob/master/config/policy.xml#L58 are the default policies that Debian sets.

Testing locally:

2022-03-03 17:52:35 thumbor:DEBUG METRICS: inc: response.count:1
2022-03-03 17:52:35 thumbor:DEBUG Format specified: png
2022-03-03 17:52:35 thumbor:DEBUG METRICS: inc: storage.miss:1
2022-03-03 17:52:35 thumbor:DEBUG Importing: wikimedia_thumbor.loader.https
2022-03-03 17:52:35 thumbor:DEBUG [HTTPS] load_sync: https%3A//upload.wikimedia.org/wikipedia/commons/7/7c/Dive_sites_of_the_Whittle_Rock_Reef_high_resolution.png
2022-03-03 17:52:35 thumbor:DEBUG [HTTPS] Loading normalized URL: https://upload.wikimedia.org/wikipedia/commons/7/7c/Dive_sites_of_the_Whittle_Rock_Reef_high_resolution.png
2022-03-03 17:52:36 thumbor:DEBUG [HTTPS] return_contents: /tmp/tmpRAu6on
2022-03-03 17:52:36 thumbor:DEBUG METRICS: inc: original_image.status.200:1
2022-03-03 17:52:36 thumbor:DEBUG METRICS: inc: original_image.response_bytes:4096
2022-03-03 17:52:36 thumbor:DEBUG [Proxy] Looking for a png engine
2022-03-03 17:52:36 thumbor:DEBUG [ExiftoolRunner] command: ['/usr/bin/exiftool', '-ImageSize', '-s', '-s', '-s', '/tmp/tmpRAu6on']
2022-03-03 17:52:36 thumbor:DEBUG [ShellRunner] Command: ['/usr/bin/timeout', '--foreground', '59', '/usr/bin/exiftool', '-ImageSize', '-s', '-s', '-s', '/tmp/tmpRAu6on']
2022-03-03 17:52:36 thumbor:DEBUG [ShellRunner] Stdout: 14040x9930

When a file description page is purged, the old thumbnails are removed from caching and cold storage (Swift). This is expected, otherwise purging wouldn't work as expected. The file was in failure throttling, which means no new attempts to thumbnail the file would be made for 1 hour. This is expected, otherwise requests for a broken file would cause a denial of service. If purging reset the failure throttle, it could be used in a DOS attack.

In T206250#4643372, @Legoktm wrote:

HISTORY says:

* New wgCategories JavaScript global variable for userscripts.

So would be worth mwgrep'ing to see what user scripts are using it. I do think removing it and replacing it with some mw.api.categories helper is a good idea (after some deprecation period of course). AFAIK though all the relevant information is already exposed via the API so removing that project.

Looks like the actual failing URL here is https://upload.wikimedia.org/wikipedia/commons/thumb/2/21/Horse_anatomy.svg/2880px-Horse_anatomy.svg.png. This is a larger-size thumbnail of an SVG that uses significant Gaussian blur, so from a Thumbor perspective this is a duplicate of T200866: rsvg-convert times out while generating large thumbnails with heavy use of Gaussian blur. If you think MediaViewer should handle the error condition differently, you can file a task for that.

Should the group-suppress and group-suppress-member messages be overridden in WikimediaMessages? It would be very annoying to create all the overrides needed in Commons to keep the name as expected. The qqq message documentation is also out of date for this use, as it refers to Flow.

Took a shot at adding support for trailing comments. I didn't do leading comments because it would be more complex and I don't have a use case for it. Matching the size to the rest of the line makes sense to me.

Thanks to T302047, I now have 89 cross-wiki notifications, mostly thanking me for my first edit on a wiki. Trying to mark them all as read silently errors.

hrm, works for me

tools.anticompositetest@tools-sgebastion-07:~$ webservice --cpu 200m --replicas 8 --backend=kubernetes python3.9 start
Starting webservice.........
tools.anticompositetest@tools-sgebastion-07:~$ kubectl get all
NAME                                    READY   STATUS    RESTARTS   AGE
pod/anticompositetest-d686cb4dc-9scv5   1/1     Running   0          3m17s
pod/anticompositetest-d686cb4dc-c97kq   1/1     Running   0          3m17s
pod/anticompositetest-d686cb4dc-gldqp   1/1     Running   0          3m19s
pod/anticompositetest-d686cb4dc-hf2jm   1/1     Running   0          3m17s
pod/anticompositetest-d686cb4dc-lsqt2   1/1     Running   0          3m17s
pod/anticompositetest-d686cb4dc-n7jqd   1/1     Running   0          3m17s
pod/anticompositetest-d686cb4dc-pvqmh   1/1     Running   0          3m18s
pod/anticompositetest-d686cb4dc-x67pz   1/1     Running   0          3m18s

No, the MIME type must match the extension in the title.

The problem mentioned in T172456#4024855 still applies. Adding support for <tvar name="1"></tvar> is fairly easy, it would just be defined as another HTML tag (since Translate doesn't register it as a parser tag). However, highlighting will break on pages that use <tvar|1></> syntax. It doesn't break horribly, but it treats the <tvar|1> tag as unclosed.

Was noted in #wikimedia-operations yesterday, before the train rolled to group0. I've been anecdotally seeing more than usual since last week (first one in my bot's logs was Feb 3).

heartbeat_p actually shouldn't be included in the list, because with the multi-instance databases it only includes lag for the current slice. So you need to connect to a different database and then query heartbeat_p.heartbeat. So it's only meta_p and centralauth_p that need to be added. So all.dblist (or maybe open.dblist, or all.dblist - private.dblist) seems like the better option

Cookie blocks show as the original block, not an autoblock, and don't have the autoblock exemption list applied. But the cookie should only have been applied if a request was made as the blocked user while they were blocked, right? And IABot would have to be sharing cookies between users. Might be worth looking in the cookie jar for any enwikiBlockID cookies.

Another report of user-facing impact in #mediawiki from someone using the w3m browser: https://wm-bot.wmcloud.org/logs/%23mediawiki/20220203.txt

On my machine using current Ghostscript and ImageMagick, gs took 20.81 seconds and convert took 14.73 seconds.

Sounds like it's autoblock-related, same as T68639/T74501: Need a way for trusted OAuth apps to make edits from blocked IPs. https://en.wikipedia.org/wiki/MediaWiki:Block-autoblock-exemptionlist does have WMF IP ranges on it though, and Cloud VPS shouldn't be handing out IPv6 addresses yet I don't think (T37947). So I'm not entirely sure what's going on there. Per https://openstack-browser.toolforge.org/server/cyberbot-exec-iabot-02.cyberbot.eqiad1.wikimedia.cloud the current floating IP should be 185.15.56.29.

In T290619#7647561, @EpicPupper wrote:

Does do-encourage and do-discourage currently have a confirmation at all or no?

In T75714#7647489, @Tgr wrote:

Since MediaWiki 1.36 (or in the case of Wikimedia wikis, rMWb267f7aa9075: resourceloader: Allow modules to mark themselves as ES6-only which was merged last March) ResourceLoader does support ES6. Is anything needed here beyond exposing the es6 ResourceLoader flag to gadgets?

T149847 would be the eventual best solution, but a cache-busting query parameter would be a good quick fix. The WMF upload-frontend cache configuration removes the query string, so we won't bust the server-side cache by adding a parameter.

if not, why (if at all) should Commons be different?

On Commons, I don't think I've ever seen this feature be useful. In pretty much every situation where a drop-down reason is sufficient to delete something, without an additional comment, the page content should not be publicly displayed. Commons has not disabled the interface message, but I think most admins regularly doing deletions remove it, either manually or with the script. I've only ever seen template markup or spam/vandalism/copyvio/LTA attack names be prefilled.

I first noticed category update problems on Commons on 5 January, but didn't pay much mind to it as I've become desensitized toward category update problems on Commons. Specifically, category updates were displayed on File pages but not on the Category page, even though they were in Special:WhatLinksHere for the cat. The numbers matched what the Category page showed.

In T216815#7610660, @Ahecht wrote:

Is any work being done on this?

Aliases backported to wmf.16, both should be deployed when the train rolls forward.

We do have some statistics in https://grafana.wikimedia.org/d/000000370/captcha-failure-rates?orgId=1 and https://grafana.wikimedia.org/d/000000004/authentication-metrics?orgId=1. The CAPTCHA failure rate is consistently at ~30%, or 100-200 per hour (rolling average). The number of attempted CAPTCHAs per hour (500-600), however, is significantly smaller than the number of displayed CAPTCHAs (which is noisy but consistently in the tens of thousands range). That would seem to imply that replacing the CAPTCHA with a "Bots go away" sign would be nearly as effective. That, or the data on displayed CAPTCHA is not being collected correctly.

By my count, there are currently 428 blocks on enwiki and 153 global blocks larger than the contribs CIDR limit. All are webhost/open proxy blocks. Only one is larger than a /24 (global 2603::/20).

Should the old namespace name be aliased to the new one, to prevent broken links?

I've rechecked everything that looked like it got dropped during the restart.

Will delaying the purge affect anything that currently checks against ipblocks and if it does, what can/should be done?

I don't believe this request meets the criteria in the Maps Terms of Use.

Wikimedia Maps may not be used by third-party services outside of the Wikimedia projects. We may make limited allowances for services that support the Wikimedia projects, such as community tools hosted on Wikimedia Cloud Services.
[...]
The following are prohibited on the Wikimedia Maps service:

1. Use for anything other than supporting the Wikimedia projects (for example, you may build a tool for Wikipedia editors, but you may not use it for an unrelated app or business)

In T290300#7354239, @Zache wrote:

In any case with mandatory authentication you will basically limit all use cases where the client side would query data dynamically for UI (say like https://wikidocumentaries-demo.wmflabs.org ) to something where user approval is asked first.