(tagging for visibility, as links coming from these extensions have been mentioned here)

Looks like the domains are still currently as described in the task description:

https://gitlab.wikimedia.org/repos/sre/miscweb/wikipedia25-years-of-wikipedia/-/blob/main/LICENSE now exists :) Feel free to reopen if there's something I've missed.

Tried to reproduce just now following the steps in the task description, & the link copied for me after clicking 'Copy link' was https://wikipedia25.org/en/which-wikipedia-of-the-future-are-you/result/1. Therefore boldly closing as resolved, but feel free to reopen if there's something I've missed :)

Is this reoccuring (or e.g. did it never stop occurring, at least for operations/mediawiki-config in the 'Everything' group)?

Just FYI, it looks like operations/mediawiki-config still contains some references to MetricsPlatform (at least some of which seem like they should probably now be removed, but others of which I'm personally unsure about).

Cross-referencing to T421831: Investigate /changes/conflicts.* Gerrit REST API timing out, which (IIUC) describes the underlying reason behind the recent [now-reversed] action to mass-abandon patches.

(as the current patch proposes a schema-change)

(After this project is created, I guess the description for @corto might want to be updated to point towards it?)

I guess the incident referenced for this task was T416456.

In T411394#11800202, @sbassett wrote:

• According to the task description of T418222: CVE-2026-39934: With hidden mentees, ReassignMenteesJob runs as an infinite loop (if I'm reading/understanding it correctly), the issue described in that task may have been occurring since 2024. However, FWICS, that task's patch was only backported to wmf/ branches, and I can't see any discussion on that task regarding backporting to release-branches as well. So I guess I'm wondering whether a fix for that task should have been backported to release-branches (and I'm also wondering whether this might affect the accuracy of its current CVE).

It's generally up to the maintainers of a given extension to fully support their backports. When the Security-Team does these releases, we make a best effort to get various security patches merged to master/main and supported release branches. But in cases like this, especially when it involves an extremely Wikimedia-specific extension, we often just ensure that the patch was merged to master/main and then defer to the component maintainers.

Yeah, I guess it seems like this might potentially be being caused by Wikimedia's production mail infra somewhere.

In T415975#11798233, @Stashbot wrote:

Mentioned in SAL (#wikimedia-operations) [2026-04-08T10:14:08Z] <hnowlan@deploy1003> Finished deploy [restbase/deploy@dcc15be]: Add urwikisource T415975 (duration: 01m 31s)

fair enough. thank you for checking! :)

hmmm... post-deploy, https://ur.wikisource.org/api/rest_v1/media/math/render/svg/a currently returns a 'route not found' error for me. (compared to e.g. https://en.wikisource.org/api/rest_v1/media/math/render/svg/a, which returns a 'not found' error, but that doesn't say that it can't find the route).

@Clement_Goubert that's the same error as T422313: MediaWiki periodic job update-special-pages-s5 failed a few days ago -- might this be duplicate auto-filed task for the same error? (and if so, might T422413 have been as well?)

Notes regarding the above draft (does not necessarily mean that something is wrong, but that I thought it was worth noting/asking about):

• [...]we would also like to provide this supplementary announcement of MediaWiki extensions and skins with now-public Phabricator tasks, security patches and backports [1]: The link at [1] is to T368628: Write and send supplementary release announcement for extensions and skins with security patches (1.39.9/1.41.3/1.42.2), which seems like a task corresponding with a previous release/announcement from 2024 (unless there's something I'm missing).
• All of the referenced Phabricator tasks appear to now be public, except for T416502.
• +(T418179, CVE-2026-39933) - Multiple XSS vulnerabilities: for consistency with previous entries on this list, should this be suffixed with "in GlobalWatchlist" (ie., Multiple XSS vulnerabilities in GlobalWatchlist)?
• +(T418254, CVE-2026-39935) - XSS-via-i18n in localised wiki names: for consistency with a previous entry on this list, should this be described as "Stored XSS through system messages" or similar? (Just as otherwise this email may be using two terms for what (IIUC) is the same category of vulnerability.)

In T388022#11795547, @A_smart_kitten wrote:

I am unsure why @Dzahn may not have received any emails from the test-instance (T388022#11783879), though. I'm not yet sure whether this is the case for e.g. all email addresses on the @wikimedia.org domain or not.
I'm aware that the Beta Cluster has had problems sending to @wikimedia.org emails in the past (T212327: Beta Cluster mailer not sending emails to @wikimedia.org addresses) -- h/t p858snake in #wikimedia-tech -- so maybe it might be related to a (possible) more general Cloud VPS → @wikimedia.org addresses email deliverability issue? Either way, I guess it might be hard to know for sure without more testing (and it seems like it might be a technically distinct issue from the one that was causing problems in this task).

I am tagging collaboration-services for your information only, feel free to triage as you see fit :)

Thanks @Pppery -- I am happy declaring this to be fixed for now :)
Since the fix was deployed (thanks again @Dzahn & @brennen!), https://phabricator.wmcloud.org/people/query/.2Jw6OEOnYXn/ shows that two accounts have been created on the test-instance, and both of them are marked as 'Verified' -- indicating (IIUC) that a confirmation email has got through to them, and that the link within it has been clicked.

See also T422455: Massive increase in "EtcdConfig failed to fetch data: Timeout was reached" warnings and errors since March 17th / T422486: MediaWiki periodic job failures due to timeouts filed today

Yeah, I was also thinking that maybe this should be closed as declined/invalid. (Given that - whatever the merits of that decision may or may not be - the Phab dump was intentionally removed in T417824)

Oh, okay :]
(I haven't been able to easily set up a properly-working local setup of Phab/Phorge so far, so T414117#11788213 was more of an educated guess than actual firm knowledge, apologies :/]

In T422220#11787773, @Dreamy_Jazz wrote:

In T422220#11787749, @matmarex wrote:

Also, it's weird that we allow GlobalBlocking to not be installed on some wikis in the farm. If I understand correctly, that means that global blocks don't apply to users on those wikis. I understand all such wikis are closed, so maybe it doesn't matter in practice, but it's still weird.

This was done to reduce the number of DB tables on production to improve performance, per request from the DBAs. No user should be able to do anything anyway on a closed wiki.

(as IIUC tasks should generally have e.g. a codebase/team project attached to them, and it seems like this task might involve the TestKitchen extension)

(@Cparle out of interest, should this also be tagged with a specific team, if there's a team that is planning to do the estimation work described in this task?)

Ah yeah (and no problem with closing this task!) - thanks for linking T422455!

For the record, the (now-public) security issue that this was caused by a patch for is T407131: CVE-2025-67479: Magic word replacement in legacy parser allows using reserved data attributes through wikitext.

Any objections from the security team/others to making this public? [xref T405790#11788879]

In T419192#11785749, @sbassett wrote:

Looks like this issue made it into master and all of the release branch backports. So we probably just need to push your follow-up patch to gerrit, merge it and backport it to same release branches. Not sure if this merits a follow-up email or not; would leave that up to @Reedy's discretion.

In T419395#11788928, @KStoller-WMF wrote:

Long-term we hope to find language that is more general and can ideally work for any WMF-maintained wiki.

I'm not sure what the best strategy would be for that once we consider a broader release.
[...]
Let us know if you have thoughts on how to approach this once we are ready for a wider rollout.

In T383948#11788145, @Toadspike wrote:

Hello folks, Echo Chamber is currently broken. I don't know if the plan to delete notifications older than 5 years has already been enacted, but if so, I'll be the "one user on any wiki" mentioned above. I first saw the Tech News announcement on 1 April tried to use Echo Chamber then, got errors, and only got around to filing T422318 today. If the deletion hasn't happened yet, could it please be postponed at least until Echo Chamber is up and running for a week or so?

Possible that this may be the same as T422313: MediaWiki periodic job update-special-pages-s5 failed & the job might not have been deleted? cc @jijiki

Possible that this may be the same as T422227: MediaWiki periodic job refreshlinks-delete-from-nonexistent-s3 failed & the job might not have been deleted? cc @jijiki

Time from that Logstash screenshot (FWICS): 2026-04-03 00:43:10

ocwikibooks Fatal error: Uncaught MediaWiki\Config\ConfigException: Failed to load configuration from etcd: (curl error: 28) Timeout was reached [truncated in screenshot] /srv/mediawiki/php-1.46.0-wmf.22/includes/Config/EtcdConfig.php:207

ocwikibooks Warning: EtcdConfig failed to fetch data: (curl error: 28) Timeout was reached in /srv/mediawiki/php-1.46.0-wmf.22/includes/Config/EtcdConfig.php on line 180

dewiki Error: 2006 MySQL server has gone away

FWICS, the time from that Logstash screenshot is 2026-04-05 05:32:22.969.
My first guess for a possible root-cause would probably have been T400133: When a database replica is depooled/rebooted, update-special-pages maintenance scripts connected to that replica seem to fail (instead of continuing with a different replica); however, looking at https://sal.toolforge.org/production?p=0&q=&d=2026-04-05, it seems like there wasn't any logged DB maintenance (or much logged anything) in prod-SAL yesterday.
Huh. Anyway, I guess we probably don't need to worry about it too much for now, unless something like this happens again :)

FWICS that logstash entry is dated 2026-04-05 00:08:54, and this task was filed on 2026-04-05 00:15. In my mind (admittedly based solely on what I remember from anecdotal experience in doing things with these automatically-filed tasks), I would therefore feel comfortable assuming that this task was filed about that error.

(replied in T422364)

In T422375#11789665, @Amitkhatri89 wrote:

Hi,

Thanks for your response.

Here are the details:

GitLab account:
I do not yet have an account on gitlab.wikimedia.org.
I only have a GitLab account on gitlab.com:
https://gitlab.com/khatriamitkumar97

Error message:
While linking LDAP in Phabricator (Settings → External Accounts → LDAP → Link External Account), I receive:
"Username or password are incorrect."

Additional details:

• I am using the same username and password as my Wikimedia (MediaWiki / Wikitech) account.
• I am able to log in successfully on Wikitech.
• My Phabricator account is also created with the same email and username.

However, LDAP authentication still fails and I am unable to link my LDAP account.

This seems like a backend or account sync issue. Could you please check if my LDAP (developer) account is properly set up or activated?

Thanks for your help.

In T383053#10471670, @MatthewVernon wrote:

Reported as Debian #1093304; more so we've a record (and in case anyone else has seen this and/or has ideas), I've not managed to find a smoking gun.

In T422130#11789154, @Marostegui wrote:

Is this good to be closed?

Noting for the record that T422327: phabricator public tasks dump is not being synced was filed yesterday

ServiceOps should hopefully be able to fetch the stack trace & error time (I believe) :)
(T417020 & T341555#10760093 onwards might have a little bit more context fwiw)

Fair enough. Speaking personally, though, it would be nice if Phab's config could be public (ie., I guess in GitLab) where it can be :)

Ah, maybe it's because https://gitlab.wikimedia.org/repos/phabricator/phabricator/-/commit/683c383986abc85ce5ccd9964ab812b26543cd0d doesn't seem to have regenerated the Celerity files?

q: Is the scope of this task maniphest.custom-field-definitions only, or is it any config setting for which the 'Database' value for production-Phabricator is different to the 'Local Config' value set in GitLab/by Scap?

Username must represent you as an individual, not an organization

In T390948#10993840, @Dzahn wrote:

Getting back to the origin of this ticket.. I think we need to first decide what we WANT to use. Do we prefer only using the repo and keeping the Horizon web UI Hiera clean? Or do we prefer to move it all to web UI? Since we all dislike the mix.. I guess it has to be one of those.

I am biased towards "repo only". The downside of that is usually that users without root/+2 in gerrit cant change the values easily but for the devtools project specifically that could be ok. I am aware of testers using services here but not so much that they change Hiera values for that.

In T421827#11783908, @SomeRandomDeveloper wrote:

Thanks, unfortunately the errors are still occuring: https://integration.wikimedia.org/ci/job/quibble-composer-mysql-php81-selenium/25520/console

In T388022#11784803, @Dzahn wrote:

This is great to hear! Sounds resolved, then.

Thanks @Zabe!

A couple of questions that've occurred to me:

• To confirm, would Security-Team/Product Safety and Integrity no longer be this extension's designated code stewards after its undeployment?
• https://meta.wikimedia.org/wiki/Special:GlobalGroupPermissions lists (FWICS) four global groups which contain the sfsblock-bypass right. Should this right be removed from these groups prior to undeployment (or e.g. would it be fine to leave it for later)?

Thank you for reviewing/merging (& fixing the puppetmaster issue) @Dzahn, & thank you for doing the scap deploy @brennen :)

thanks, and no worries @JMeybohm :D

thanks for fetching @JMeybohm, the top of the stack trace appears to be missing though? (ie., IIUC there should be the error message & some frames before #5)

(fyi)

I was just about to file a partial duplicate of this task without realising :)
I was gonna suggest adding a confirmation box/window after clicking "Run Puppet Compiler" if there isn't a Hosts: footer in a patch's commit-message, but just not running PCC at all in that scenario also seems fine from my perspective (so long as there'd still be a way to get PCC to run for all hosts, if this is something that is occasionally genuinely needed).

From a first look, it seems like the line in question may have actually been changed prior to the patch being merged into the Git repo -- was e.g. the release tarball published before this? (Might we need a new patch release to account for this?)