Adding translatewiki.net so someone can see if the above can be addressed

@KingChristLike: just to check, have you lost access to your KingChristLike account? I assume that's yours.

For the record, https://github.com/miraheze/MirahezeMagic/commit/63f32d0609bafbd49ba1c03a38d953c8121afdc1 fixes this

In T379499#10331157, @Aklapper wrote:

As far as I know MirahezeMagic Override does not track its issues in Wikimedia Phabricator? See also the description on https://phabricator.wikimedia.org/project/profile/6096/

This feels like it should really be reported downstream to us but it's tiny so I'll just fix it

What does this have to do with Gerrit?

That we can do automatically. The stats pull can be told as a one off to follow redirects.

This is a test commebt

@Daimona: this has broken beta update databases. See https://integration.wikimedia.org/ci/job/beta-update-databases-eqiad/79353/

@Mstyles @sbassett: any reason this can't be public

You can create an LDAP / Developer account at https://idm.wikimedia.org/signup/

It still feels like I'm talking to GPT but

I'm not sure what this is going to gain.

In T370632#10003626, @sbassett wrote:

Thanks, @Yaron_Koren. Miraheze folks - are you ok with us making this task public now? This will also be re-announced within the next supplemental security release.

I imagine paste is probably the far more well used that property.

Reopen so security see at triage

@Mstyles: can you add this to the supplemental and seek CVE record?

In T367856#10056182, @GTrang wrote:

If one is pessimistic, then the enwiki.analytics.db.svc.wikimedia.cloud replag will continue to increase for all eternity. This would mean that the replag would increase to 9,000 hours on August 13, 2025, if this task is still not completed by then. Otherwise, if one is optimistic, then the replag will eventually go back to zero.

Replication lag is normal during these schema changes. It will naturally go down significantly faster than it went up once the change completes.

In T372022#10050428, @Xaosflux wrote:

Lock actions are not secret, so this is certainly not an inappropriate information disclosure problem; no issues with it being turned off if it is useless noise though.

Possible Patch from @TheVoidwalker:

In T368594#9941121, @sbassett wrote:

In T368594#9941019, @RhinosF1 wrote:

@sbassett: would you mind if this bug was shared wider with the Miraheze team to see if we can look at doing something? It's used quite widely on our farm so I'd rather not see the extension archived if there's the possibility of someone maintaining it.

Should be fine if you want to sub a few relevant Phab users here, to discuss internally. Or even open a new, public Phab bug in regards to ext:CSS owner/maintainership.

Thanks Scott. I've added a few of our team.

@sbassett: would you mind if this bug was shared wider with the Miraheze team to see if we can look at doing something? It's used quite widely on our farm so I'd rather not see the extension archived if there's the possibility of someone maintaining it.

In T368594#9940883, @Bawolff wrote:

Cc'ing some people i think are associated with miraheze/wikiforge

Test - ignore

@Aklapper removed projects: Data-Engineering, Analytics-Data-Problem.

Why? @Gehel says this is owned by Data-Engineering

In T188236#9857925, @Igorsolovki wrote:

not sure if it helps but mainpage is saying

Effective June 1, 2021: Phabricator is no longer actively maintained.

I'm not sure what that's got to to do with this task. This is a bug in mediawiki and has nothing to do with the underlying software used to report the bug.

Both of these will be automatically fixed I believe when the relevant scripts have been ran.

Wiki Created by @Zabe

In T365644#9827614, @Chocapikk1337 wrote:

I also have another question. I don't think this is necessary. But a CVE ID can be assigned to this bug or not? If yes, how is it going? Do I do the process or do you?

And I want to confirm that the vulnerability is indeed fixed after some tests.

We've been running Phorge since T333885: Migrate phabricator.wikimedia.org to Phorge as upstream

Adding project tags for areas affected

I am discussing this task with a steward on IRC

11:04:05 <@Urbanecm> RhinosF1: wargo: i tired, it did not help. however, manually constructing the URL where the thumbnail is supposed to be (https://upload.wikimedia.org/wikipedia/commons/thumb/archive/8/82/20230929224435%21PL_JI_Kraszewski_Zygzaki.djvu/page1-87px-PL_JI_Kraszewski_Zygzaki.djvu.jpg) appears to have worked

In T297942#9644062, @Wargo wrote:

Maybe RefreshImageMetadata.php on PL_JI_Kraszewski_Zygzaki.djvu would help?

In T353904#9642344, @sbassett wrote:

In T353904#9641879, @RhinosF1 wrote:

I added the ManageWiki one too.

Thanks. @Mstyles - we should plan to include these with the upcoming release, and I don't think we need to worry about any release-branch backports for them.

In T353904#9529744, @sbassett wrote:

In T353904#9526984, @RhinosF1 wrote:

I've added https://github.com/miraheze/WikiDiscover/security/advisories/GHSA-cfcf-94jv-455f to the tracker listing the GSHA as there's no task for it on Wikimedia. WikiTide have requested the CVE.

Thanks.

With thanks to Martin, this is now deployed.

I will get the patch deployed this evening ready for you

In T360357#9639368, @Ezarate wrote:

Hi RhinosF1, one day of duration (24 hs) y 30 persons maximum and 100 new articles created. Regards!!!

To provide needed info

Can you also advise the time of the event and duration?

Can you advise the expected number of creations?

@Yug: why does this need task need to be dealt with by @Reedy in particular ?

Likely T358597: urldownloader1003's network is unresponsive