Security access granted

@abi_ Great, I'll post the review by the end of February so you have plenty of time.

@abi_ Is this project still scheduled for deployment on Jan 31? I wanted to follow up on the timeline.

In T410560#11497430, @Daimona wrote:

Yep, sorry everyone for the confusion. The current status here is that the patch needs code review, and I am re-linking it below for convenience:

T410560.patch5 KBDownload

However, I should also note that, holidays aside, the team is currently a bit understaffed and we aren't treating this as the #1 priority.

In T410560#11497841, @Daimona wrote:

In T410560#11497707, @sbassett wrote:

In T410560#11497430, @Daimona wrote:

Yep, sorry everyone for the confusion. The current status here is that the patch needs code review, and I am re-linking it below for convenience:

However, I should also note that, holidays aside, the team is currently a bit understaffed and we aren't treating this as the #1 priority.

Ok. We'd really like to get something into the supplemental security release we're trying to get out by the end of this week. Should we use the current production patch instead? Or the updated patch with maybe a note that it isn't completely tested and isn't fully-supported at this time, or something like that?

Gotcha, I'll see what we can do then. If anything, I think including the production patch is fine.

Wikibase Extension
+ (T409737, CVE-2026-22710) - Stored XSS through autocomment system messages
https://gerrit.wikimedia.org/r/q/I8505700afda8096ef4e183280494232152767004

@Urbanecm_WMF I'm not sure what's causing the failures. I'll take a look.

@SomeRandomDeveloper thank you and I see I used the wrong tag for gerrit, apologies!

In T409737#11444393, @Lucas_Werkmeister_WMDE wrote:

In T409737#11444135, @SomeRandomDeveloper wrote:

T409737-REL1_44.patch920 BDownload

Haven’t confirmed that it applies to the different branches but CR+1 for the patch contents – should be okay to try applying to the branches when the time comes.

In T410560#11456249, @Daimona wrote:

Bah, I ended up doing this as a non-public fix. Don't ask me why :D I simply avoided injecting stuff to keep the diff minimal, and disabled a unit test that would otherwise fail. So, this is now ready for review:

T410560.patch5 KBDownload

(Note that this supersedes the currently-deployed patch from T410560#11400896)

CVE/Backport Assignments

@Urbanecm following up on this task in the new year

Since this is a simple extension rename, an application security review is not needed

Since all users now have 2FA access I'm declining this task as I don't think it's relevant anymore.

@Adarsh2406 your patch looks pretty good and it addressed a lot of the issues that @Reedy mentioned. I wonder if you would be interested in reopening your patch?

Now that we have 2FA and all users have access to it (T399664) I'm marking this as resolved.

As all of the cleanup work is either merged or deployed and all users have access to 2FA, I'm marking this as resolved.

In T411144#11411297, @SomeRandomDeveloper wrote:

Updated patch which also escapes growthexperiments-mentorship-enrollasmentor-summary:

T411144-2.patch1 KBDownload

In T407157#11358704, @SomeRandomDeveloper wrote:

Fixed version of the patch in T407157#11356911 to use .find instead of .children so all elements are selected:

01-T407157-open-link-in-new-tab-2.patch7 KBDownload

In T399664#11361969, @Bugreporter wrote:

The oathauth-enable right

3rd party wikis may still only allow certain user using 2FA (since they may have few people handling account recovery requests). Alternatively we can assign it to user in Wikimedia projects and MediaWiki default and remove it from other groups currently holding that right.

Security issue access has been granted

We decided to not show timestamps for recovery codes per the designs, unless this is referring to something else

I assume they should all have index=-1. Otherwise, tabbing through the page takes you to the footer before it takes you to the form inputs.

We're in the process of improving passkey support and are planning to make major changes in the next few weeks. I think the changes should allow a greater variety of passkeys to work. Right now we've limited passkeys to roaming only, so you should not be getting an error

@dom_walden what do you think the tab order should be for the images listed? Outside of the WebAuthn error page, I think that the other pages seem to tab okay and the tab index increases. Is it that the bottom of the page has tab index set to 0 that's an issue for the other pages?

In T401772#11307840, @A_smart_kitten wrote:

In T401772#11151390, @Tgr wrote:

(The names will eventually be editable, right?)

+1 to the names being editable - otherwise, for anyone that's currently added more than one authenticator app (and can currently remember which is which), they presumably won't be able to give them more descriptive names without removing & re-adding them.
(Also, if someone e.g. changes phone in a way that allows them to transfer the data stored by their authenticator app, a previously-entered name may end up no longer being accurate - e.g., someone might originally name an app "Authy on iPhone 13", which then wouldn't be accurate if they upgraded to an iPhone 15.)