I found it as well, but it's different from the requested logo. I'm happy to use that svg, but I'm not sure whether that is desired.

Merged as https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PushToWatch/+/643575.

Thank you!

@MF-Warburg I'd like to also ask for a SVG version of the logo. https://upload.wikimedia.org/wikipedia/commons/3/32/Wikipedia-logo-v2-skr.png cannot be used, because it is a) too small (the minimum is 270px * 310px, and we strongly prefer a SVG version) b) it doesn't have transparent background (so the logo would have a white background in the browser). Compare https://en.wikipedia.org/static/images/project-logos/cswiki.png and https://upload.wikimedia.org/wikipedia/commons/3/32/Wikipedia-logo-v2-skr.png in a google chrome (or any other browser that signalizes transparent background).

@MF-Warburg According to WMF Board's licensing policy (https://foundation.wikimedia.org/wiki/Resolution:Licensing_policy), any project with local uploads enabled needs to have an exemption doctrine policy, that describes under which conditions can non-free media be uploaded. Can you please link that policy as well (prepared either at incubator or meta), so we can review it?

I'll prepare initial config.

I'll prepare initial config.

In T268583#6643413, @Reedy wrote:

Seemingly caused by rMWd45e2fef6d67: SECURITY: Prevent invoking firejail's --output functionality from T258763: Vulnerabilities in firejail due to --output (CVE-2020-17367, CVE-2020-17368)

Unclear why it didn't affect the fawiki vote...

@jrbs Hello, it just needs to be purged. Given votewiki is edited so infrequently, the automatic purge does not happen immediately. I made a null edit, and it's fixed.

In T228521#6638332, @Teles wrote:

I just tested with my own account and it seems to be working fine. Could that be related with something specific that was used by that account (Tuga1143)? Or a script like Fastbuttons?

In T267668#6636494, @CptViraj wrote:

It's displaying correctly for me...

Sorry @Krinkle, but reopening again. The test case mentioned in my reopening comment: https://cs.wikipedia.org/w/index.php?title=Wikipedista:Martin_Urbanec/P%C3%ADskovi%C5%A1t%C4%9B/3&oldid=19177452, is still broken. Both images exist at Commons, and none displays. Purging did not help.

I do not think that this got fixed completely, see https://cs.wikipedia.org/w/index.php?title=Wikipedista:Martin_Urbanec/P%C3%ADskovi%C5%A1t%C4%9B/3&oldid=19177452. It's a recently moved file, but it sounds very similar to this one. Reopening.

Possibly, I closed (and auto-claimed, which caused project to be auto-added by herald), and you then set the assignee to yourself. Anyway, no problem :).

(adding my personal project back so I can easily look up tasks that are important for me in the future)

I enabled the extension at metawiki beta. It will take a while to propagate, but it should work. Please reopen if it doesn't.

Did a second HTCP purge after Puppet propagated it everywhere, and it seems to work:

This is not within Operations scope. T&S should either grant themselves, or post a request at the steward request page.

In T263220#6626432, @Bawolff wrote:

Note: A config change is needed in wmf-config before the patch will take affect.

Note it is not possible to create an account using an username that was in use previously. If user:Foo gets renamed to User:Bar, no one (but administrators) can register User:Foo. It was possible for a long time, and it is a relatively recent change, but it's not possible today.

Hey @Borislav, as you're still logged in, could you make an edit referencing this task, to confirm its authenticity? Thanks, Martin

We could, but people having the gadget enabled globally (via global.js) would have two links, which is not easily avoidable at this point. The best thing would be to fix the issue itself, and I created T267925 for that. I can look into that later today I guess.

Hello @patilise, thanks for creating this task! AFAICS, the sidebar link is inserted in onSidebarBeforeOutput. There's an if that short-circuits the hook, which requires $wgUrlShortenerReadOnly || !$wgUrlShortenerEnableSidebar to be false in order to insert the link. However, in Wikimedia production, wgUrlShortenerReadOnly is true at all wikis but metawiki (that is to make sure throttling works). For that reason, merely setting $wgUrlShortenerEnableSidebar to true would not help, given the sidebar link would display only at metawiki.

@ppelerg Exactly.

Stated rename got processed by the system. Note the job queue has variable speed, the more jobs MediaWiki submits, the slower renamings get. Give it some time to stabilize, please. If it won't fix itself after few days, please open a new task.

Happy to hear that @Yerpo

Well this one was easy, the account was created by Yerpo themselves, and apparently is a bot account operated by Yerpo.

Looking into this

Thanks for your prompt fix, as always :).

Fixed. Some images had a fix URL starting with new-web.wordpress.wikimedia.cz. Replaced that with wordpress.wikimedia.cz, which will always be accessible.

See T233235: Add Urbanecm to #mediawiki_security and T239093: Add Daimona to #mediawiki_security for past such requests. See T239093#5804013 for info how to do this.

Thanks @tstarling!

In T260455#6621107, @tstarling wrote:

I reopened this task on the basis that it describes leakage of usernames into the toolforge replica due to T260485, whereas T205460 is a catch-all failure mode. I would like someone to confirm that the T260485 aspect is resolved.

Thanks @Krinkle and everyone else who was involved in this!

@Tgr I didn't try that to be honest, as it isn't in scope of this task (it says implement the redirect, which was done). If we want to track the Upstream bug, I'd say create a follow-up task.

Deployed.

That's because @Gilles did some logos optimization in T252108. As part of the optimization, the optimization part changed from plain optipng -o7 to a different set of commands, see https://wikitech.wikimedia.org/wiki/Wikimedia_site_requests#Change_the_logo_of_a_Wikimedia_wiki. It seems that this issue got introduced exactly because of the optimization, see T252108#6541194 for details. @Gilles Could you please have a look and investigate whether that is the issue?

@DannyS712 You already seem to be in #wikimedia-security. Feel free to join :-).

So, I just noticed this issue while debugging why I cannot log in to a newly-added wiki to WMCZ's wikifarm. The reason is that the actor table at the new wiki is empty, which makes User::newFromName() return an invalid user object.

Certified from my side, as I failed to spot anything else.

The redirect works fine for me - closing as resolved.