The localised wiki names displayed on the "Contributions" tab of Special:EventDetails are coming from the project-localized-name-* messages, and are output without escaping (text() only).
Description
Description
Details
Details
- Risk Rating
- Low
- Author Affiliation
- WMF Product
Related Changes in Gerrit:
Related Objects
Related Objects
Event Timeline
Comment Actions
CR+2, LGTM. I think we can try to get this deployed during next Monday's (2026-03-02) security window.
Comment Actions
@sbassett Hi, has the patch been deployed? If so, can we proceed with the public patch now, considering that it only needs a master fix per T418254#11645995.
Comment Actions
Hey, sadly, it looks like this one didn't go out during Monday's window. I can try to get it out today after the late backport window. And then we can open up the task.
Comment Actions
Change #1249320 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):
[mediawiki/extensions/CampaignEvents@master] SECURITY: EventContributionsPager: escape wiki names for display
Comment Actions
Change #1249320 merged by jenkins-bot:
[mediawiki/extensions/CampaignEvents@master] SECURITY: EventContributionsPager: escape wiki names for display
Comment Actions
The fix can be verified with $wgUseXssLanguage on a non-empty contribution tab.
And it should be possible to undeploy the security patch with next week's train.
Comment Actions
Patch is blocking upcoming release
Patch 01-T418254.patch is currently failing to apply for the most recent code in the mainline branch of extensions/CampaignEvents. This is blocking MediaWiki release 1.46.0-wmf.20(T413811)
If the patch needs to be rebased
A new version of the patch can be placed at the right location in the deployment server with the following Scap command:
REVISED_PATCH=<path_to_revised_patch> scap update-patch --message-body 'Rebase to solve merge conflicts' /srv/patches/next/extensions/CampaignEvents/01-T418254.patch "$REVISED_PATCH"
If the patch has been made public
The patch can be dropped in the deployment server with the following Scap command:
scap remove-patch --message-body 'Dropping patch already made public' /srv/patches/next/extensions/CampaignEvents/01-T418254.patch
Comment Actions
commit a7829842fd2c224b75d24428ad0cab8631d73b82 (HEAD -> master)
Author: Alexander Vorwerk <zabe@avorwerk.net>
Date: Sat Mar 14 00:55:51 2026 +0000
Scap remove-patch: removed 1 patch
Dropping patch already made public
Removed patches:
next:
- extensions/CampaignEvents/01-T418254.patchComment Actions
No, the patch has landed in master and testing instructions from T418254#11706736 are still valid.
The bot in T418254#11709279 warned that the previously applied private patch in production would no longer apply with this week's train due to a conflict, which is expected because the fix is now public. BUT, the fix was not backported to wmf.19; so, does that mean that production is currently not patched?
Comment Actions
The patch is still on wmf.19 in production:
( ^◡^)> pwd /srv/mediawiki-staging/php-1.46.0-wmf.19/extensions/CampaignEvents
( ^◡^)> git log --graph --decorate --oneline -n5 * b363c975 (HEAD) SECURITY: EventContributionsPager: escape wiki names for display ...
Since the master patch got merged last week, it should make the cut today for wmf.20. And then the wmf.19 patch will "fall off" production. SecurityPatchBot is just aggressive in trying to call out potential conflicts with security patches before they happen.
Comment Actions
I see, thank you! I'm not familiar with the process, hence my question. I'll keep that in mind going forwards.
Comment Actions
Sure, the high-level process looks a bit like:
- We push security patches up to deployment under various version-related staging directories
- We deploy these patches via scap, typically during the Monday security deployment window, but sometimes throughout the week
- If any of those patches conflict (due to public changes in the code or publicly merging the security patch), SecurityPatchBot uses a "next" directory to try to find these issues early and alert the security team and release engineering
- The aforementioned process ^ doesn't directly remove or modify any existing, applied security patches within Wikimedia production, it just alerts
- Though scap won't apply any conflicting security patches (technically it can't anyways) it finds (it considers them "dropped" or "released" in this context)
- The dropped/released security patches get cleaned up by the security team or release engineering throughout the week
Comment Actions
Thanks for the explanation, bookmarked for future reference :D
So, this task can be QAed as noted in T418254#11706736.