I've added @Blake to acl*security_sre.

In T412120#11454221, @kostajh wrote:

perhaps we could have a Herald rule that auto-subscribes relevant users?

Security Review Summary - T404738 - 2025-12-05
Last commit reviewed: 4a614aa4c0

In T411381#11443062, @Novem_Linguae wrote:

Hello friends. Thanks for your consideration. Any updates/ETA?

Confirming @MLechvien-WMF has Phab 2fa enabled. @Kappakayala and @MLechvien-WMF - would you be able to provide a bit more detail about the need for this request? e.g. specific lines of work and Phabricator task examples that @MLechvien-WMF need access to? Thanks.

I've added you as a basic member to security@. Let us know if you need anything else.

In T404738#11440662, @jsn.sherman wrote:

@sbassett just checking in; do you have what you need to review this week?

Ping @EMill-WMF for awareness. This will likely be handled at our next clinic on 2025-12-08.

In T399459#11427691, @Ifrahkhanyaree_WMDE wrote:

Hi there, checking in on behalf of the Wikibase Reuse team - is the plan to still have the review done by end of this year?

Currently stalled on efforts to better define and formalize Wikimedia's Phab access policies for volunteers and community members.

Ping @EMill-WMF for review.

In T411126#11416019, @SomeRandomDeveloper wrote:

The skin was imported from Github, so in theory it only supports the master branch. In the gerrit repository, there are only two release branches which would still be supported (REL1_39 and REL1_45). The skin is currently unmaintained and I'm the only active contributor, so I suppose I'm going to specify the compatibility policy on mediawiki.org as "master" as I don't think it's worth backporting the change to the release branches since there are a lot of merge conflicts.

In T410755#11406544, @Aydinnyunus wrote:

https://gerrit.wikimedia.org/r/c/pywikibot/core/+/1210626/1/pywikibot/login.py

https://github.com/wikimedia/pywikibot/commit/a0fea2b175943c338fb901737a069a837e1402cc

Er, is there a specific change set or merge request that fixes the actual RCE? I didn't see an obvious one in gerrit or at github. https://gerrit.wikimedia.org/r/c/pywikibot/core/+/1210674 just updates the security policy.

Just scanning over https://gerrit.wikimedia.org/r/q/T401987, it looks like all of the backports have landed? And the hard deprecation is on master and in Wikimedia production, ready for 1.46 when it gets cut. So I think we can at least tentatively resolve this for now.

In T410420#11404181, @Neslihan_Turan_WMDE wrote:

Done :) Sorry for the delay I was sick off previous week.

Playing around with this a bit locally, I think we either need to change the copy for the oathauth-delete-warning message or introduce a different code path/message. Because the code appears to be working properly in recognizing existing/remaining auth app keys. When I inspect $lastKey, $this->isPrivilegedUser() and even count( $remainingKeys ), all of those appear correct when I have 2+ auth app keys set for my account. But the only path the code can take in this case is rendering the oathauth-delete-warning message via: Html::element( 'p', [], $this->msg( 'oathauth-delete-warning' )->text() ) ); on line 641 of OATHManage.php.

In T404738#11401254, @jsn.sherman wrote:

Hi @sbassett, just checking in: how are things looking?

Update

1. The hard deprecation xslt patch is now merged on master, 1.46.0-wmf.3 (and deployed to Wikimedia production). There's also a currently-conflicted version of the patch up for review for REL1_45.
2. The softer xslt deprecation patch is also now up for review for REL1_44 and REL1_43.

In T409855#11393107, @dancy wrote:

I do strongly recommend the use of scap update-patch and scap remove-patch to move patches in and out of /srv/patches, even in the manual workflow. @sbassett If those tools are not adequate in some way, please let me know so I can make adjustments.

In T409743#11392822, @Aklapper wrote:

The sec patch will and must get removed before 22:00, as it will block proceeding with the train at 19:00 UTC.

In T409855#11391442, @Lucas_Werkmeister_WMDE wrote:

So scap update-patch and scap remove-patch are not part of the recommended patch management method, despite the git hook asking people to use it?

In T409743#11391179, @Zabe wrote:

^ The sec patch can be removed from prod since it got trough Gerrit.

Hey @brennen - Any idea why I'd be getting errors about a non-existent path when trying to run some really basic CI? Sample job failure: https://gitlab.wikimedia.org/repos/projects/user-scripts-data-tooling/-/jobs/683407

# trying to install poetry via pip
... 
Installing collected packages: typing-extensions, pycparser, urllib3, sniffio, idna, h11, exceptiongroup, charset-normalizer, cffi, certifi, zipp, requests, msgpack, jeepney, httpcore, cryptography, backports.tarfile, anyio, zstandard, tomli, SecretStorage, rapidfuzz, pyproject-hooks, platformdirs, pbs-installer, packaging, jaraco.functools, jaraco.context, jaraco.classes, importlib-metadata, httpx, filelock, distlib, crashtest, cachecontrol, virtualenv, trove-classifiers, tomlkit, shellingham, requests-toolbelt, poetry-core, pkginfo, keyring, installer, findpython, fastjsonschema, dulwich, cleo, build, poetry
ERROR: Could not install packages due to an EnvironmentError: [Errno 13] Permission denied: '/nonexistent'
Check the permissions.
Cleaning up project directory and file based variables
00:00
ERROR: Job failed: command terminated with exit code 1

Thanks and let me know if I should file a separate bug.

In T409855#11389752, @Dzahn wrote:

@sbassett Ah, I see! Gotcha. Yea, I think that would be helpful.

In T409855#11371744, @Dzahn wrote:

how do we best keep this group of people informed

How about putting the manual method you described on the docs page? That would have worked and it seems that's all this ticket is asking for.

Per the 2025-11-18 meeting, next steps are:

1. @ssingh and Traffic to clean up and optimize the most recent, existing vcl patch
2. @ssingh to schedule deployment time for new config (likely within about 2 weeks)
3. @ssingh and Product Safety and Integrity to alert relevant WMF / Community folks (specifically test engineers)
4. Product Safety and Integrity to evaluate relevant CSP log data and determine if a rollback is necessary (this should only be the case if there are extreme disruptions on testwiki or report-only logspam)

In T297428#11367075, @taavi wrote:

I think https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/5d5a3c0720520f75e723d3b5a37e793a6e674e4f%5E%21/ makes this obsolete?

In T409855#11370703, @Lucas_Werkmeister_WMDE wrote:

So what is the officially sanctioned or maintained way to deploy security patches, then?

This functionality is likely only necessary under the single recovery code model which, as has been noted, is not the current configuration within Wikimedia production and likely never will be again.

fake gerritbot: https://gerrit.wikimedia.org/r/q/Iec8d9490e000fccd7340681617a88e3d0afabdca

Just noting again that deploy_security.py isn't really officially sanctioned or maintained by anyone on the Security-Team or Product Safety and Integrity.

In T297428#11363243, @LSobanski wrote:

@sbassett, @daniel The last comment makes this look urgent and it was posted 4 years ago. Is this still an issue and should it be prioritized?

In T117618#11360663, @ssingh wrote:

Hi @sbassett. Yes that sounds good, let's set up a time to talk about this and move it forward.

In T409743#11361312, @Catrope wrote:

Quick patch to fix the immediate problem:

0001-SECURITY-Handle-legacy-non-edit-cascading-protection.patch1 KBDownload

Verified that @Peter has Phab 2fa enabled.

In T117618#11224896, @ssingh wrote:

Commenting from Traffic's side: this is in some ways, a trivial patch for us because we are simply setting an additional header. The challenge here, though, is understanding the header itself and the associated ramifications of setting it and also keeping it updated. For that, the Security should be/needs to be consulted, so this patch currently blocks on that happening.

Hey @brennen - Thanks! Looks like we're all good here.

Thanks, @jsn.sherman. Is there a more specific deployment date for this code? Not that this review would necessarily block such a milestone.