Note that this occurs on every wiki where the suppressed user has an account. Loginwiki is simply the easiest place to find this information.

Thanks for filing this. I don't see block ID 9694 in the output of https://login.wikimedia.org/w/api.php?action=query&format=json&list=blocks&formatversion=2&bkshow=temp, are you saying that you see block 9694 in the ouptut when making that query as a logged-out user?

In T397595#10937278, @kostajh wrote:

Thanks for filing this. I don't see block ID 9694 in the output of https://login.wikimedia.org/w/api.php?action=query&format=json&list=blocks&formatversion=2&bkshow=temp, are you saying that you see block 9694 in the ouptut when making that query as a logged-out user?

That block has expired by now, "expiry": "2025-06-23T04:52:31Z", but yes but I was able to see it while logged out.

Given this was caused by a lock suppress, this will likely be a fix to MediaWiki-extensions-CentralAuth. Tagging as such.

I’ve noticed that Special:AutoBlockList (https://login.wikimedia.org/wiki/Special:AutoblockList) does correctly hide the autoblock, but Special:BlockList and the Blocks API show it with no issue. Possibly MediaWiki-Blocks -related? Tagging for visibility.

Now that I understand the problem some more, I think this isn't necessarily a fix to MediaWiki-extensions-CentralAuth. The block should have been hidden as it says "username hidden" for the parameters and isn't shown at the autoblock list, so it seems an issue specifically with how local autoblocks are hidden.

This appears to have been caused by Multiblocks, specifically 60911137ef7e445b93ed345e0e0b066db272e322.

The issue here is that bl_deleted is no longer checked because the assumption was made that querying to see if the local user was hidden would be enough. Because the local user might not exist, using that method is not reliable. Checking bl_deleted appears to still be necessary in this case.

Therefore, tagging this as Multiblocks work.

Am I missing something or this is an issue with autoblocks in general and not specifically related to global account suppressions or CentralAuth?

In T397595#10938187, @Dreamy_Jazz wrote:

This appears to have been caused by Multiblocks, specifically 60911137ef7e445b93ed345e0e0b066db272e322.

The issue here is that bl_deleted is no longer checked because the assumption was made that querying to see if the local user was hidden would be enough. Because the local user might not exist, using that method is not reliable. Checking bl_deleted appears to still be necessary in this case.

Therefore, tagging this as Multiblocks work.

I've been looking around at it seems that the expression we add here fails to filter out ip blocks (autoblocks) with bt_deleted. Is this what you are referring to @Dreamy_Jazz ?

In T397595#10940116, @dmaza wrote:

Am I missing something or this is an issue with autoblocks in general and not specifically related to global account suppressions or CentralAuth?

I believe this is specific to a CentralAuth setup because the local user doesn't exist, so the autoblock cannot look up whether the local user is hidden for the "hide this block" check.

I believe this would be fixed by checking against bl_deleted as opposed to bt_deleted.

Does this fix the issue? cc @tstarling and @MusikAnimal for CR

@XXBlackburnXx I followed those steps locally and can't reproduce the issue on Special:BlockList. Only on the Api

@XXBlackburnXx I followed those steps locally and can't reproduce the issue on Special:BlockList. Only on the Api

I can reproduce it on login.wikimedia.org for the Special:BlockList. I see blocks autoblocks marked as "username hidden" when logged in also display to the user while logged out.

I suspect though that any fix would be identical to the API, given that Special:AutoBlockList (which doesn't have the issue) applies the bl_deleted check: https://gerrit.wikimedia.org/g/mediawiki/core/+/c7bdfb0ca7c557ef67c611a02294b7b056e20d46/includes/specials/SpecialAutoblockList.php#123

In T397595#10948724, @Dreamy_Jazz wrote:

@XXBlackburnXx I followed those steps locally and can't reproduce the issue on Special:BlockList. Only on the Api

I can reproduce it on login.wikimedia.org for the Special:BlockList. I see blocks autoblocks marked as "username hidden" when logged in also display to the user while logged out.

I suspect though that any fix would be identical to the API, given that Special:AutoBlockList (which doesn't have the issue) applies the bl_deleted check: https://gerrit.wikimedia.org/g/mediawiki/core/+/c7bdfb0ca7c557ef67c611a02294b7b056e20d46/includes/specials/SpecialAutoblockList.php#123

Interesting. If I'm not mistaken that condition on SpecialAutoblockList is unnecessary since it is also added on BlockListPager. See https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/c7bdfb0ca7c557ef67c611a02294b7b056e20d46/includes/specials/pagers/BlockListPager.php#518. No idea how or why SpecialBlockList is not working since both use the same pager.

You are right, I can see the issue on login.wikimedia.org, but I can't figure out how to reproduce it locally so I'm unable to debug it. I have to admit I'm not very familiar with CentralAuth if that's the root of the issue. I'm clearly missing something. I'll keep poking around

Production has the security patch F59065606 for T391343, deployed since April.

if ( $this->getAuthority()->isAllowed( 'hideuser' ) ) {
        $info['fields']['hu_deleted'] = $this->hideUserUtils->getExpression(
                $db,
                'block_target.bt_user',
                HideUserUtils::HIDDEN_USERS
        );
} else {
        $info['fields']['hu_deleted'] = 0;
        $info['conds'][] = $this->hideUserUtils->getExpression(
                $db,
                'block_target.bt_user',
                HideUserUtils::SHOWN_USERS
        );
}

So there's no bl_deleted condition in production.

This patch needs to be applied after the one for T391343.

@dmaza's patch looks good to me and can be deployed.

Note that hidden usernames are shown to users who are blocked by the autoblock. That's probably always been the case. My patch above addresses this issue by redacting the name in the autoblock reason.

Per https://wikitech.wikimedia.org/wiki/How_to_deploy_code#Guidelines_for_creating_patches, security patches should not modify i18n files. This is because modifying them causes all deployments to go slower.

The page recommends hard coding the message text in the security patch and then making them message strings once the patch is uploaded to gerrit.

Can the above patch be modified to not modify i18n files.

In T397595#10957312, @Dreamy_Jazz wrote:

Per https://wikitech.wikimedia.org/wiki/How_to_deploy_code#Guidelines_for_creating_patches, security patches should not modify i18n files. This is because modifying them causes all deployments to go slower.

The page recommends hard coding the message text in the security patch and then making them message strings once the patch is uploaded to gerrit.

Can the above patch be modified to not modify i18n files.

I see from T389302 @Reedy that the pre-release announcement is already out promising a security release today.

I don't know if I want to miss that boat and have an unlocalised feature in production for four months.

In T397595#10957715, @tstarling wrote:

I see from T389302 @Reedy that the pre-release announcement is already out promising a security release today.

I don't know if I want to miss that boat and have an unlocalised feature in production for four months.

Sure, but AFAIK it needs to be deployed to production before it can be released in a security release. Therefore, it needs to be in a security patch even if it is for a day or two.

Perhaps uploading to gerrit and backporting to all wmf branches is okay from a Security-Team point of view but I don't think I've ever seen that as a way to fix it.

In T397595#10957098, @tstarling wrote:

This patch needs to be applied after the one for T391343.

0002-SECURITY-Fix-leak-of-hidden-usernames-via-autoblocks.patch7 KBDownload

@dmaza's patch looks good to me and can be deployed.

The comment in BlockListPager says "Since 1.45, a hidden target name is not included in the autoblock reason.". However, that won't be the case once the fix is backported. Could we instead link to the task?

Alternatively, it could be updated once patches are created in gerrit. Lastly, it may be too much of a nit-pick point to address.

I'm splitting up the patch so that the bl_deleted part is the security patch. The name redaction (which requires i18n) is not the bug reported here and is arguably not a security bug at all and maybe can just go into master.

In T397595#10957784, @tstarling wrote:

I'm splitting up the patch so that the bl_deleted part is the security patch. The name redaction (which requires i18n) is not the bug reported here and is arguably not a security bug at all and maybe can just go into master.

Thanks.

AFAIK, both the patch from T397595#10948652 and the one to be created by tstarling would need to be used to fix the problems described in this ticket.

Noting that this bug is actually an unreleased bug in the security patch scheduled for release today, I would ideally like my new bl_deleted patch F62709792 and also @dmaza's bl_deleted patch F62466463 to be deployed urgently and also applied to the release.

@sbassett for the above

I'm guessing these are to REL1_43 like T391343 then?

In T397595#10958560, @Reedy wrote:

I'm guessing these are to REL1_43 like T391343 then?

Yes

In T397595#10957312, @Dreamy_Jazz wrote:

Per https://wikitech.wikimedia.org/wiki/How_to_deploy_code#Guidelines_for_creating_patches, security patches should not modify i18n files. This is because modifying them causes all deployments to go slower.

Sure, but it's also not that big of a deal. Since @tstarling's more complete patch is already done and looks good, it's fine to just deploy that with a sync-world.

In T397595#10957797, @tstarling wrote:

Noting that this bug is actually an unreleased bug in the security patch scheduled for release today, I would ideally like my new bl_deleted patch F62709792 and also @dmaza's bl_deleted patch F62466463 to be deployed urgently and also applied to the release.

I'm fine deploying the larger i18n patch as a security patch (see my reasoning above). To confirm:

1. The conflicting patch from T391343 will fall off of production today or tomorrow, as it is slated to be a part of the core security release that will come out hopefully today.
2. Until that happens, we'll want to deploy (soon):
   1. @tstarling's updated patch at F62699593
   2. @dmaza's patch for this specific issue at F62466463

And then I assume we're ok? Or, at worst, we'll have to pick the patch from T391343 to 1.45.0-wmf.8 to ensure it rolls out with this week's train?

In T397595#10958919, @sbassett wrote:

In T397595#10957797, @tstarling wrote:

Noting that this bug is actually an unreleased bug in the security patch scheduled for release today, I would ideally like my new bl_deleted patch F62709792 and also @dmaza's bl_deleted patch F62466463 to be deployed urgently and also applied to the release.

I'm fine deploying the larger i18n patch as a security patch (see my reasoning above). To confirm:

1. The conflicting patch from T391343 will fall off of production today or tomorrow, as it is slated to be a part of the core security release that will come out hopefully today.
2. Until that happens, we'll want to deploy (soon):
   1. @tstarling's updated patch at F62699593
   2. @dmaza's patch for this specific issue at F62466463

Both are done, and staged into the .8 patch directory, which doesn't yet have a /srv/mediawiki-staging checkout on disk.

@Dreamy_Jazz has confirmed tested they're working as intended.

In T397595#10958919, @sbassett wrote:

And then I assume we're ok? Or, at worst, we'll have to pick the patch from T391343 to 1.45.0-wmf.8 to ensure it rolls out with this week's train?

Tim's larger patch, F62699593 needs rebasing due to the duplication of the two patches (not a big issue).

By the time Tim is up tomorrow, that should all be settled, and he can move that forward.

Can be backported to the supported release branches (sorry REL1_42) as appropriate.

In T397595#10958987, @Reedy wrote:

Both are done, and staged into the .8 patch directory, which doesn't yet have a /srv/mediawiki-staging checkout on disk.

@Dreamy_Jazz has confirmed tested they're working as intended.

Awesome, thanks.

Tim's larger patch, F62699593 needs rebasing due to the duplication of the two patches (not a big issue).

Sounds good, thanks.

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

[mediawiki/core@REL1_43] SECURITY: Fix autoblocks visibility when bl_deleted=1

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

Change #1165078 had a related patch set uploaded (by Reedy; author: Tim Starling):

[mediawiki/core@REL1_43] SECURITY: Fix leak of hidden usernames via autoblocks of those users

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

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

[mediawiki/core@REL1_44] SECURITY: Fix autoblocks visibility when bl_deleted=1

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

Change #1165104 had a related patch set uploaded (by Reedy; author: Tim Starling):

[mediawiki/core@REL1_44] SECURITY: Fix leak of hidden usernames via autoblocks of those users

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

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

[mediawiki/core@master] SECURITY: Fix autoblocks visibility when bl_deleted=1

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

Change #1165119 had a related patch set uploaded (by Reedy; author: Tim Starling):

[mediawiki/core@master] SECURITY: Fix leak of hidden usernames via autoblocks of those users

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

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

[mediawiki/core@REL1_42] SECURITY: Fix autoblocks visibility when bl_deleted=1

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

Change #1165139 had a related patch set uploaded (by Reedy; author: Tim Starling):

[mediawiki/core@REL1_42] SECURITY: Fix leak of hidden usernames via autoblocks of those users

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

Change #1165103 merged by jenkins-bot:

[mediawiki/core@REL1_44] SECURITY: Fix autoblocks visibility when bl_deleted=1

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

Change #1165104 merged by jenkins-bot:

[mediawiki/core@REL1_44] SECURITY: Fix leak of hidden usernames via autoblocks of those users

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

Change #1165118 merged by jenkins-bot:

[mediawiki/core@master] SECURITY: Fix autoblocks visibility when bl_deleted=1

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

Change #1165119 merged by jenkins-bot:

[mediawiki/core@master] SECURITY: Fix leak of hidden usernames via autoblocks of those users

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

Change #1165138 merged by Reedy:

[mediawiki/core@REL1_42] SECURITY: Fix autoblocks visibility when bl_deleted=1

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

Change #1165139 merged by Reedy:

[mediawiki/core@REL1_42] SECURITY: Fix leak of hidden usernames via autoblocks of those users

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

Change #1165077 merged by Reedy:

[mediawiki/core@REL1_43] SECURITY: Fix autoblocks visibility when bl_deleted=1

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

Change #1165078 merged by Reedy:

[mediawiki/core@REL1_43] SECURITY: Fix leak of hidden usernames via autoblocks of those users

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