I believe this request should be granted. As documented by the list @Novem_Linguae created in the description, they are routinely helping with security tickets in components that are neglected by other developers, such as SecurePoll or Flaggedrevs. Novem Linguae is already a +2 holder (granted in T364531), which indicates a great amount of trust, and as far as I can see, they exercise their judgement with care.

Switching to my volunteer Steward Liason role: We should be extra careful here before we make it happen. Assuming the rate limit between named and temporary accounts is not shared, switching to regular accounts when temporary ones are exhausted (or vice-versa) is the quickest way to bypass Six Account Limit (and make it a Twelve-Account-Limit instead). I'm not 100% sure how to account for this, but we should consider this risk and incorporate it into the decisions we make here.

@pmiazga reached out to me about this task. I tried it out, and the result is available as https://people.wikimedia.org/~urbanecm/screencasts/T256185.webm. It seems to work now (likely because we have now removed the .m. domain).

That URL address...should never be actually generated by anything. MediaWiki sometimes uses links in the format of en.wikipedia.org/w/index.php?oldid=xxx and/or en.wikipedia.org/w/index.php?curid=xxx (such as https://en.wikipedia.org/w/index.php?oldid=1316080086 or https://en.wikipedia.org/w/index.php?curid=162281). Is there a realistic example of how this can be triggered?

I'm not sure about this. On one hand, I absolutely agree we should care of the good first tasks to make sure they're good. On the other hand, I'm unsure if time is a good indicator. From my experience, even simplish tasks (=take me up to 30 minutes to figure out and write a patch) are often left untouched for a good while. This is because every such task eats a bit of my resources (and the reviewer's resources too) and being humans, we only have finite amount of resources.

Noting that I just received a community question about this :). It looks like the error message is way less confusing in the newer form, thank you for working on this!

Both Phabricator accounts are now disabled. Note I'm also happy to add you to acl*userdisable if you're interested, to be able to self-serve account disabling.

Okay... It is not visible in the management interface (as eg. autoconfirmed is), but it _is_ visible via the API.

In T403298#11135615, @JMeybohm wrote:

Please keep in mind that allowing the HTTP proxy IPs will ultimately allow Enterprise API access from all systems allowed to use the HTTP proxies, not only analytics/stats hosts.

This task was created based on a discussion with @prabhat, see WMF Slack.

SRE: Would you mind confirming the appropriate IPs or ranges that would need to be allowlisted to include analytics cluster?
Wikimedia Enterprise: Would you mind doing the allowlist once the IPs are confirmed?

Hello @Gallemore, thank you for reporting this. Nothing really changed per se. MediaWiki treats spaces and underscores as equivalent (docs) and as far as my memory serves, this was always the case. It is possible whatever tool you are using to process/request the data has changed the representation it sends to its users, but I can't comment in more details on that without details about how you access page title-related data. In any case, as long as you communicate with MediaWiki directly, it shouldn't matter whether you use spaces or underscores, as they are equal to each other.

CC @MusikAnimal as the patch author (seems to originate from https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CommunityRequests/+/1165637).

I think we are mixing two questions here:

@RLazarus Do you have any thoughts on how to tackle this one, please?

I also noticed that even if the code was executed, the announcement would be somehow broken (at least on MW-on-K8s), as SUDO_USER is no longer populated. I filled T401803: mwscript-k8s does not include an environment variable with the username of the executing user for this problem.

I changed that setting and copy-pasted AddWiki:: notifyNewProjects() into a shell.php session. I tested that with both my staff address and the list. Both messages got sent properly, and I can see the list one in list archives. So, the issue seems to be that AddWiki is simply not executing the notifying codepath for some reason.

In T393444#11080985, @Peachey88 wrote:

Do we know who the list owner(/s) are to confirm its not the mailman side (eg emails getting accidently moderated)?

I went ahead and deployed @Zabe's patch. This is now done. Thank you all!

In T400755#11045169, @Urbanecm wrote:

[...] FTR, I also flagged this to T&S (pointing out staff group has this user right as well, and probably shouldn't).

In T400755#11045145, @Zabe wrote:

Threw a comment at https://meta.wikimedia.org/wiki/Stewards%27_noticeboard#Remove_the_centralauth-unmerge_right_from_the_steward_group

In T400755#11045155, @Xaosflux wrote:

"community-elected group of users" is a bit of a specific discriminator; noting that this is not the only group of volunteers that have this access; as it is included in the global group 'sysadmin' which includes volunteers

I wondering whether this should be completed in the first place. If we decided administrators do not need the unblocking permission, this should apply for blocks by filters as well, right? If we do this, I'm wondering where would be the line where unblocks need to be done by another admin.

See prior convo in T327034 about this.

Other thing I'm wondering about: Among other things, Autoreveal suppresses logging of individual reveals. I'm wondering about what are the possible routes to trigger that effect if you want to hide you revealed something. But not sure if this opens any other avenues besides enabling the full autoreveal experience.

@Dreamy_Jazz Hmm, that seems to also mean I can enable autoreveal for the next 20 years if I want to:

Thanks for filling this! Definitely something to look into and fix.

In T396951#10915828, @A_smart_kitten wrote:

Might be worth bearing this (September 2023) comment from another GitHub issue in mind — I don't know whether/to what extent it's still an issue, but it seemed worth flagging here just in case:

https://github.com/freeotp/freeotp-android/issues/334#issuecomment-1711954232:

👋 GitHub PM for Identity here. We use an 80 bit secret for compatibility with Google Authenticator, which had a bug for a very long time around longer secrets. It's unclear if they've since fixed it since it was abandonware for so long - now that they've updated it to support sync, maybe they fixed that too.

@EMill-WMF For your awareness. This causes issues with the mandatory 2FA rollout we're currently working on. Would you mind flagging this to the appropriate subteam, please?

In T386492#10859924, @Tchanders wrote:

In T386492#10798615, @JJMC89 wrote:

In T386492#10797269, @Tchanders wrote:

Global groups that have the checkuser-temporary-account or checkuser-temporary-account-no-preference right should also have the checkuser-temporary-account-auto-reveal right. A list of rights assigned to global groups can be seen at: https://meta.wikimedia.org/wiki/Special:GlobalGroupPermissions

Would we need to ask a community member to add the checkuser-temporary-account-auto-reveal right to the relevant global groups?

Yes, a steward needs to do this.

@Urbanecm Would you be happy to do this?

@Dreamy_Jazz and I discussed this at Wikimedia-Hackathon-2025. Dreamy_Jazz pointed out this might happen if a cookie block gets involved. After some testing, I can confirm that hypothesis, a cookie block is issued for IP hard blocks. I previously wasn't able to reproduce on desktop, but I was testing this with a soft-blocked IP instead.

That is the expected behavior, then I did everything correctly. Can we move stewards-l to actual runs then, please?

Please see T351202#10616848 for a more general note on moving the maillists (other than stewards-l).

A general note on this: The biggest remaining problem to solve is the "it is very hard to see what you just done" problem. When running the sync, the onboarder tool doesn't tell you what changes are being made (as compared to the current maillist membership), mostly because it does not have a way how. Here is how the Gitlab integration currently behaves (for comparison and a "ideal end result" description):

@Dzahn Boldly assigning to you for step (1)!

@Dzahn Would you mind helping with this, please?

Noting @jrbs was added to the group in T220860, in order to be able to run changePassword.php on Wikitech (which back then was linked to LDAP directly). Running modify-ldap-userseems to be the today equivalent to that. I'm not sure if we want to allow password/email resets via Bitu.

I asked @Melos to email @KFrancis with their details to start the NDA process as well.

Approved from my end.

In T386479#10554979, @Nemoralis wrote:

@Urbanecm can we add Special:MyLanguage/ to wizard links? Wizard is translatable.

Resolving, as the patch has been merged.

In T351202#10529743, @Dzahn wrote:

Would it be useful to run dry-run syncs that don't actually modify things but show what _would_ happen and then email those out to you (a group)?

Filled T386410: TranslatableBundleMover does not lift the lock if an asynchronous move failed to be schedule as a related issue (when moving a translatable page, it erroneously stays locked even though the job was not actually scheduled, and thus no move is happening).

Happening for me as well (when moving translatable pages). Moved ~10 pages and got the error for 3 of them. I looked through the logs and found this:

In T385808#10532691, @KFrancis wrote:

Hi all, I checked my records, and I do have have a NDA for anything under kwa.schultz@gmail.com or user EP1C. What is this person's full name?

In T385833#10536830, @Stashbot wrote:

Mentioned in SAL (#wikimedia-operations) [2025-02-10T21:23:38Z] <urbanecm> Start namespaceDupes.php on shwiktionary (T385833)

Approved.

In T351202#10506235, @Dzahn wrote:

@Urbanecm What's the latest here? Anything waiting for me or my team here? Would you consider this stalled for now?

Started to receive emails for wmcz-stats about this:

Done (both).