Untagging Security-Team as it looks like WMDE plans to review this? Since this extension is Wikimedia-production-deployed, please code-review on this task and do not push the patch to gerrit. Once reviewed, the Security-Team can assist with a Wikimedia production deployment.

In T394938#10860051, @sbassett wrote:

Untagging Security-Team as it looks like WMDE plans to review this? Since this extension is Wikimedia-production-deployed, please code-review on this task and do not push the patch to gerrit. Once reviewed, the Security-Team can assist with a Wikimedia production deployment.

A bit late for that one. As per my email to security-help and flag by @Urbanecm in _security on IRC, this has been public for 48 hours on gerrit and afaik not deployed to production.

To add onto the above, the patch also hasn't been backported to any other branches than master, so Miraheze is currently not able to fix the vulnerability, despite it being public through Gerrit.
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/TwoColConflict/+/1150011

Please don't remove SecTeam-Processed. That's an internal tag for the Security-Team's tracking.

This is already on 1.45.0-wmf.3, so at this point it just needs to ride the train the rest of the week to land in Wikimedia production. For most of these message XSS issues, we've traditionally considered them low risk since you'd need to compromise the MediaWiki message as well, which is non-trivial for unprivileged users.

Once a patch is up in gerrit, it can be backported by pretty much anyone. I can get those started now for supported release versions.

Change #1151259 had a related patch set uploaded (by SBassett; author: WMDE-Fisch):

[mediawiki/extensions/TwoColConflict@REL1_44] Make sure the i18n msg for the preview is escaped

https://gerrit.wikimedia.org/r/1151259

Change #1151260 had a related patch set uploaded (by SBassett; author: WMDE-Fisch):

[mediawiki/extensions/TwoColConflict@REL1_43] Make sure the i18n msg for the preview is escaped

https://gerrit.wikimedia.org/r/1151260

Change #1151261 had a related patch set uploaded (by SBassett; author: WMDE-Fisch):

[mediawiki/extensions/TwoColConflict@REL1_42] Make sure the i18n msg for the preview is escaped

https://gerrit.wikimedia.org/r/1151261

Change #1151262 had a related patch set uploaded (by SBassett; author: WMDE-Fisch):

[mediawiki/extensions/TwoColConflict@REL1_39] Make sure the i18n msg for the preview is escaped

https://gerrit.wikimedia.org/r/1151262

In T394938#10860243, @sbassett wrote:

Please don't remove SecTeam-Processed. That's an internal tag for the Security-Team's tracking.

I removed it because it needed to be brought to security team's attention again because somehow the report in _security & via email was completely missed.

This is already on 1.45.0-wmf.3, so at this point it just needs to ride the train the rest of the week to land in Wikimedia production. For most of these message XSS issues, we've traditionally considered them low risk since you'd need to compromise the MediaWiki message as well, which is non-trivial for unprivileged users.

Once a patch is up in gerrit, it can be backported by pretty much anyone. I can get those started now for supported release versions.

There is still a process to follow though that security team are supposed to manage for WMF Deployed code. If this was a third party extension, we'd normally wait on task for your triage and for you to determine whether it's safe to be made public via a gerrit patch (and normally ensure that patch gets a speedy review). For a WMF Deployed Security issue, you guys are supposed to help us manage the private patch and deployment process to ensure WMF wikis are patched before the issue is exposed and normally would then release yourselves at security release time. This task has gone against the norm for reasons I'm not certain of but the lack of engagement is again embarrassing.

As far as I can tell, _security was ignored. My email wasn't read. The patch was +2'd despite already being merged. This isn't an effective security release and someone needs to explain why again we're chasing the basics.

Change #1151259 merged by jenkins-bot:

[mediawiki/extensions/TwoColConflict@REL1_44] Make sure the i18n msg for the preview is escaped

https://gerrit.wikimedia.org/r/1151259

In T394938#10860312, @RhinosF1 wrote:

I removed it because it needed to be brought to security team's attention again because somehow the report in _security & via email was completely missed.

It's not for you to remove. Please do not do it again. There are other ways of contacting the Security-Team, as you've mentioned above. Both of which did receive replies as you have incorrectly noted here. Two on-call WMF staff members both correctly described this issue as low risk and not an immediate worry in #mediawiki_security, responding to @Urbanecm's message. That answer should absolutely have sufficed. I also replied to your email this morning and noted that the security team would be getting to these issues today during our clinic, which was delayed due to a Monday US holiday and an ongoing Wikimedia production incident. The Security-Team does not have unlimited resources nor do we guarantee 24/7 on-call services for every possible security-related issue.

There is still a process to follow though that security team are supposed to manage for WMF Deployed code. If this was a third party extension, we'd normally wait on task for your triage and for you to determine whether it's safe to be made public via a gerrit patch (and normally ensure that patch gets a speedy review). For a WMF Deployed Security issue, you guys are supposed to help us manage the private patch and deployment process to ensure WMF wikis are patched before the issue is exposed and normally would then release yourselves at security release time. This task has gone against the norm for reasons I'm not certain of but the lack of engagement is again embarrassing.

Processes are great when they are followed. That wasn't the case here and not due to the actions of anyone on the Security-Team. When incidents like this happen, people have to take out-of-process actions to correct the matter, which doesn't always happen perfectly and instantly.

As far as I can tell, _security was ignored. My email wasn't read. The patch was +2'd despite already being merged. This isn't an effective security release and someone needs to explain why again we're chasing the basics.

Most of this is incorrect as I mentioned above. I gave a quick +2 because from the comments on this task, it seemed like the patch hadn't been merged yet, nor cut for 1.45.0-wmf.3, both of which were incorrect. You're free to form your own opinions but I would advise not doing so on false assumptions and misinformation.

Change #1151260 merged by jenkins-bot:

[mediawiki/extensions/TwoColConflict@REL1_43] Make sure the i18n msg for the preview is escaped

https://gerrit.wikimedia.org/r/1151260

In T394938#10860464, @sbassett wrote:

In T394938#10860312, @RhinosF1 wrote:

I removed it because it needed to be brought to security team's attention again because somehow the report in _security & via email was completely missed.

It's not for you to remove. Please do not do it again. There are other ways of contacting the Security-Team, as you've mentioned above. Both of which did receive replies as you have incorrectly noted here. Two on-call WMF staff members both correctly described this issue as low risk and not an immediate worry in #mediawiki_security, responding to @Urbanecm's message. That answer should absolutely have sufficed. I also replied to your email this morning and noted that the security team would be getting to these issues today during our clinic, which was delayed due to a Monday US holiday and an ongoing Wikimedia production incident. The Security-Team does not have unlimited resources nor do we guarantee 24/7 on-call services for every possible security-related issue.

There is still a process to follow though that security team are supposed to manage for WMF Deployed code. If this was a third party extension, we'd normally wait on task for your triage and for you to determine whether it's safe to be made public via a gerrit patch (and normally ensure that patch gets a speedy review). For a WMF Deployed Security issue, you guys are supposed to help us manage the private patch and deployment process to ensure WMF wikis are patched before the issue is exposed and normally would then release yourselves at security release time. This task has gone against the norm for reasons I'm not certain of but the lack of engagement is again embarrassing.

Processes are great when they are followed. That wasn't the case here and not due to the actions of anyone on the Security-Team. When incidents like this happen, people have to take out-of-process actions to correct the matter, which doesn't always happen perfectly and instantly.

As far as I can tell, _security was ignored. My email wasn't read. The patch was +2'd despite already being merged. This isn't an effective security release and someone needs to explain why again we're chasing the basics.

Most of this is incorrect as I mentioned above. I gave a quick +2 because from the comments on this task, it seemed like the patch hadn't been merged yet, nor cut for 1.45.0-wmf.3, both of which were incorrect. You're free to form your own opinions but I would advise not doing so on false assumptions and misinformation.

Scott, I've replied to you via email. I don't think this Phabricator task is the place to air my concerns but I still have a number of them.

Change #1151261 merged by jenkins-bot:

[mediawiki/extensions/TwoColConflict@REL1_42] Make sure the i18n msg for the preview is escaped

https://gerrit.wikimedia.org/r/1151261

Change #1172065 had a related patch set uploaded (by SBassett; author: SBassett):

[mediawiki/core@REL1_39] Fix strtolower(): Passing null to parameter #1 ($string) of type string is deprecated

https://gerrit.wikimedia.org/r/1172065

Change #1151262 merged by Jly:

[mediawiki/extensions/TwoColConflict@REL1_39] Make sure the i18n msg for the preview is escaped

https://gerrit.wikimedia.org/r/1151262

Change #1172065 abandoned by SBassett:

[mediawiki/core@REL1_39] Fix "strtolower(): Passing null to parameter..." error

https://gerrit.wikimedia.org/r/1172065