It doesn't have to be a physical device, but we're proposing to currently limit passkeys to physical devices until we get proper Web Authn support

What is the benefit of adding the right directly vs adding users to a group?

Not sure how to make that more clear. If a randomly selected user (part of whatever percent rollout we are doing) is not a member of any of the other global groups then they get added to the oathauth-tester group.

In T399665#11008747, @Reedy wrote:

Ideally we will also be able to prevent users from enabling passkeys unless they are using a physical device.

Any particular reason?

@kostajh mentioned that we could also consider an event logging collection since there is a low volume of events

Actually can you create them as milestones and not subprojects?

Can you also create the following subprojects:

I ended up keeping both pages since https://www.mediawiki.org/wiki/Developing_security_patches talks about more than just Gerrit. I still left the technical patch documentation in https://wikitech.wikimedia.org/wiki/How_to_deploy_code#Security_patches. Definitely open to feedback about further changes.

Marking as invalid since we were not able to reproduce this issue on our side. Feel free to reopen @Wikinaut if you still see any issues.

Security issue access granted!

@Dwisehaupt if you have any questions, please let me know. Otherwise, I will mark this as resolved at the end of this week.

Security Review Summary - T385337 - 2025-06-23

@Lakejason0, Thank you for working on this issue. In the future can you put patches up privately as outlined in developing security patches. It would be ideal to get this patch merged today.

Since this release is backported to 1.41 and 1.42 and there's been no response about the 1.39 patch for some time, I'm going to mark this ticket as resolved.

@Wikinaut can you verify the reproduction steps that @Jly posted?

The ML team now has security issue access!

Thank you so much @brennen!

I assigned it to you @Aklapper because it looked like you did this in other situations such as T331170. I'll follow up with my team to find out if anyone has CLI access

@Wikinaut We did not try to reproduce in the version that you reported it in, just in 1.44.0. I'll find out if we can reproduce in 1.41.0

In T396230#10891525, @sbassett wrote:

In T396230#10891432, @Michael wrote:

This should work as expected. However, I'm not actually able to test it locally on my machine because I do not have emailing set up locally (yet). This should be kept in mind when reviewing:

T396230.patch1 KBDownload

CR+1, we should be able to get this deployed during this Monday's security window. Would be nice (but not essential IMO) to get another set of eyes on this for review before then.

In T395063#10897445, @sbassett wrote:

In T395063#10895709, @Krinkle wrote:

I suggest mentioning this task (T395063) in the two inline comments. LGTM, otherwise!

Done here:

01-T395063.patch2 KBDownload

Security issue access granted

Thanks so much @KFrancis. @Paladox we will need you to add 2FA to your account before security issue access can be granted. Please set up 2FA.

You can update the View Policy by clicking on the Custom policy in Phab and adding a View Policy manually. I also sent a screenshot to explain

In T394869#10844674, @sbassett wrote:

In T394869#10844606, @SomeRandomDeveloper wrote:

Updated patch:

T394869.patch1019 BDownload

Is it correctly formatted now?

Yep, CR+1, LGTM.

In T394612#10835925, @SomeRandomDeveloper wrote:

In T394612#10835735, @sbassett wrote:

In T394612#10833075, @SomeRandomDeveloper wrote:

Patch:

Quiz.diff1 KBDownload

This looks reasonable to me. This should likely just get pushed through gerrit for public review since it's not bundled or Wikimedia-deployed. This can be done now or closer to the end of our quarter (2025-05-30) when we'll issue the next supplemental security release (T389312).

https://github.com/wikimedia/operations-mediawiki-config/blob/af3cd130d2b848052f93fc106ae4ebe8aa659f20/wmf-config/InitialiseSettings.php#L4097
Quiz is deployed on wikinews, wikiversity, wikibooks and three wikipedias.

In T394397#10865690, @dmaza wrote:

02-T394397.patch2 KBDownload

Woops. Not sure how I missed that. Thank you.

It seems that the plural syntax is currently broken on that message so that's a different issue.

In T395622#10876475, @sbassett wrote:

In T395622#10869366, @Daimona wrote:

As usual, I'm assuming this to be low-risk since it's via i18n, but still, adding the patch here:

T395622.patch1 KBDownload

CR+2, we'll plan to get this deployed during today's (2025-06-02) security window.

@Yaron_Koren sorry for not making that clear, checking in the change to Gerrit was exactly what I meant.

@Yaron_Koren when you review this patch, it can go ahead and go through Gerrit since this extension is not deployed on WMF servers.

+1 to this patch and going to get this out in today's security deploy. Adding support to the phan-taint-check-plugin for these issues is a great idea and I'll ping about a follow up task in case that doesn't happen.

@KFrancis any update for the NDA since it's been signed?

If you 're still able to see the task, then you can confirm that you have access. I added acl*release_security_pre_announce as a view group, I didn't replace the acl*security policy. I already did this for T392746.

I reached out to Legal and they do not have a NDA signed for @Paladox. Could you go ahead and start that process?

I'm following up with Legal and any other internal concerns and will report back with more information

@Aklapper using the acl*release_security_pre_announce project worked so I'm resolving this ticket. We can reopen it if something is needed in the future.

@dmaza @lwatson you recently addressed a codex issue in T394396, do you think you could take a look at this issue?

@Dreamy_Jazz thank you for reporting this issue. I'll ask around and see if anyone is interested in working on this.

@Dreamy_Jazz are you intending to work on this ticket or should I look for another contributor?

Since this would only be for a few tasks per year @Aklapper, changing the View Policy for a few tasks would be okay.

@Aklapper if you could create the ACL with the security team as the manager that would be great.

@Aklapper I can provide more information offline, if that would be helpful.

@Reedy for the testing issues with 1.39, would you recommend just merging as is with the tests failing or taking a different approach?

Do you have any test plans or paths or code that you can point to as well for this issue?

Thank you for this report. This is not replicable in 1.44.0, If you could provide any more information, that would be appreciated

@STran are these patches ready for deployment? I would like to make sure they get out sooner than later.

I am not sure if this issue still exists. I tried to change the owner of my binary and wasn't able to exactly replicate this issue. However, I did fix a different update message and I added the change to this ticket.

@STran @BlankEclair what are the status on these patches. I've reviewed them and they look good to me, but it seems that there's still active work ongoing. I can wait until next week to deploy if necessary.

In T392341#10760715, @STran wrote:

ArchivePage.php and UnarchivePage.php require token

T392341_1.patch4 KBDownload

Security issue access granted

Still working on backports for 1.39 and 1.42

@Dwisehaupt thank you for the update.

Hey @Dwisehaupt do you have a particular date for this python package to go into production? I'll be doing a fairly quick vendor review.

The supply chain report has been shared to all relevant persons and a lot of feedback has been taken into account. I'm marking this ticket as closed, but feel free to reopen if there is any follow up.

Once we get the backport merged for 1_39, we want to make this ticket public. Any objections?