The SecurePoll extension is already installed on enwiki.

Change #1083870 had a related patch set uploaded (by Dreamrimmer; author: Dreamrimmer):

[operations/mediawiki-config@master] Enable electionadmin user group on enwiki

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

I suggest stalling this until T377531 is resolved.

At the moment, it sounds like enwiki wants to put all the SecurePoll perms in the electionadmin user group. Having all the perms in the same group that they were basically in before means that the unbundling in T377531 will have no effect on this ticket, right? May not need to stall this.

As for the social/consensus side of things, we can create the electionadmin group as a first step, then not give it to anyone until we hammer out the details of how it will be given out. The exact process for giving it out is still being discussed on enwiki, but there is a consensus to have SecurePoll on enwiki and to have electionadmins.

WP:SNOW: unanimous support to have the ability to hold local SecurePoll elections, including enabling the electionadmin right on enwiki. An RFC to determine how the new right should be distributed can be launched at any time; it may be advisable to advertise that RFC on WP:CENT. --Levivich

Would the line $wgGroupPermissions['electionadmin']['securepoll-administrate-poll'] = true; cause any problems if securepoll-administrate-poll isn't created yet?

In T378287#10271579, @Novem_Linguae wrote:

Would the line $wgGroupPermissions['electionadmin']['securepoll-administrate-poll'] = true; cause any problems if securepoll-administrate-poll isn't created yet?

This wouldn't cause any problems, but it would be redundant in the codebase, so leaving it for now is the best approach. For now, we can create the electionadmin user group with existing rights, and later, if there are any updates, we can add more rights as needed. I think creating this user group is harmless since no one can add or remove it at the moment (except stewards). When the community decides who can grant access to this user group and to whom, we can then add the configurations for wgAddGroups and wgRemoveGroups.

In T378287#10271575, @Novem_Linguae wrote:

At the moment, it sounds like enwiki wants to put all the SecurePoll perms in the electionadmin user group.

In https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(idea_lab)#Determining_who_should_be_an_electionadmin, there is just one user who appears to suggest putting all perms in one group.

There are more people who suggest bundling poll creation and editing into sysop, and view-voter-pii into CheckUser. If that is the eventual consensus, we don't need the electionadmin group at all.

Also, it's just an idea lab discussion, likely a prelude to a more organized VPR discussion or RfC which the closer of https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Enabling_SecurePoll_elections_with_the_electionadmin_right suggested should happen before enwiki deployment:

An RFC to determine how the new right should be distributed can be launched at any time; it may be advisable to advertise that RFC on WP:CENT.

It would help if T377531 is resolved before such a discussion happens.

I'd be in favor of getting this deployed so the electionadmin group exists. This would get the technical part out of the way. Then, onwiki and at the community's convenience, we can workshop a policy/guideline for which users it can be granted to.

I think this will be ready for deployment once the two code review comments are resolved.

I would like to avoid decision paralysis here.

I will tweak the patch shortly.

Hi @Novem_Linguae , is such investigate still in progress? And may I know what kind of database challenge is facing, is it related to T381197 or not?

I'll reach out to @SDeckelmann-WMF via email and see if I can get an update. The discussion is currently off phabricator I think. Would be great to get it moved onto phabricator to make progress a bit easier to track.

@Novem_Linguae I can look into it. Let me get back to you with more information shortly.

Thanks!

In terms of SecurePoll database scalability (which I believe is the concern), my understanding is that there's only issues for global elections, because a maintenance script is used to generate a table of authorized voters for every single wiki. Naturally that does not scale. I first learned about this after reading T355594: For global elections, stop creating eligible voters table for each election on every wiki and keeping them forever.

But my understanding is that a local election that only involves one wiki doesn't generate any extra tables, and just uses the existing 12 SecurePoll tables already installed on that wiki. Please let me know if I'm misunderstanding something.

In T378287#10475973, @Novem_Linguae wrote:

Thanks!

In terms of SecurePoll database scalability (which I believe is the concern), my understanding is that there's only issues for global elections, because a maintenance script is used to generate a table of authorized voters for every single wiki. Naturally that does not scale. I first learned about this after reading T355594: For global elections, stop creating eligible voters table for each election on every wiki and keeping them forever.

But my understanding is that a local election that only involves one wiki doesn't generate any extra tables, and just uses the existing 12 SecurePoll tables already installed on that wiki. Please let me know if I'm misunderstanding something.

This is correct. SecurePoll supports local elections through its base tables and if you're curious about the process around global elections, you can read this documentation. I don't think the global databases will block local elections but SecurePoll making assumptions about the access to global elections may. T384302: SecurePoll: Restrict creation of foreign and global elections tracks the work needed to gate some of those features. IIRC, SecurePoll was intended to run on votewiki and therefore although it supports local elections, in practice it assumes any election it runs will be global and therefore whoever is has permission to administrate it it has permissions to do global things, will be running the support cli scripts, etc.

This needs some engineering specification to see what we can decouple from global elections permissions, so moving it to the "Needs engineering specification" column.

Per the WMF TSP team, we will probably wait to do this until security ticket T392341: CVE-2025-53483, CVE-2025-53484, CVE-2025-53485: SecurePoll is vulnerable to XSS, CSRF, and lack of authorisation is resolved. ETA couple of days to a week.

@Novem_Linguae Possibly that ticket is resolved as of a few hours ago? Per: https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=2298496&oldid=2298493

In T378287#10797708, @Leijurv wrote:

@Novem_Linguae Possibly that ticket is resolved as of a few hours ago? Per: https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=2298496&oldid=2298493

There's still outstanding work on that task but we will give notice here once this is ready to move forward.

Sounds like the security stuff will be fixed on Thursday, and https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1083870 can be scheduled for backport on Friday or later.

Can someone please mark that patch as active instead of WIP?

It seems to have been marked as active since May 2 for me.

In T378287#10881759, @Novem_Linguae wrote:

can be scheduled for backport on Friday or later.

Fridays are no-deployment days. In general this should wait until next week so that any unexpected train complications don't cause additional issues with this.

In T378287#10882019, @Pppery wrote:

It seems to have been marked as active since May 2 for me.

I "rebased with merge conflicts" a couple times and it wasn't my patch, so it knocked it into WIP status and I wasn't able to put it back to active status. Then Mate and Dreamy Jazz and others would come along to put it back to active status. Dreamy Jazz did it today (thanks Dreamy)

This is a complicated ticket so I will recap it for whoever does the backport:

• English Wikipedia approved this ticket through an onwiki consensus on May 2, 2025.
• Selena Deckelmann approved this ticket in an email to me on May 1, 2025.
• This ticket was approved by WMF TSP team on Apr 23 2025, 1:45 AM. See mszabo's edit to the original post above where he ticks off the box "consult with Trust & Safety Product team to see if any other modifications to SecurePoll are needed".
• Shortly after that, this ticket was put on hold by WMF TSP team due to SecurePoll security ticket T392341.
• T392341 now has 5 public patches that rode the train and should fully resolve that security ticket. See comment T392341#10881738

It seems to me that everything is resolved and ready to move forward. With that in mind, I asked DreamRimmer to schedule https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1083870 for backport.

In T378287#10797991, @mszabo wrote:

In T378287#10797708, @Leijurv wrote:

@Novem_Linguae Possibly that ticket is resolved as of a few hours ago? Per: https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=2298496&oldid=2298493

There's still outstanding work on that task but we will give notice here once this is ready to move forward.

Cross-linking IRC conversation with Maté:

15:16 <urbanecm> DreamRimmer: i see the last info on the task from TSP is https://phabricator.wikimedia.org/T378287#10797991, which says "we will give notice here once this is ready to move forward". i don't see that on the task, only a summary from NovemLinguae that links to a checkbox checked _prior_ to mszabo saying they'll comment in the future
15:16 <urbanecm> let me quickly sync with mszabo to double check
15:17 <mszabo> urbanecm: yes this is good to go sorry

Change #1083870 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable electionclerk user group on enwiki

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

Mentioned in SAL (#wikimedia-operations) [2025-06-10T13:22:57Z] <sgimeno@deploy1003> Started scap sync-world: Backport for [[gerrit:1083870|Enable electionclerk user group on enwiki (T378287)]], [[gerrit:1154369|core-Permissions:Restrict editing on cawikimedia to autoconfirmed only (T396178)]]

Mentioned in SAL (#wikimedia-operations) [2025-06-10T13:24:58Z] <sgimeno@deploy1003> bunnypranav, dreamrimmer, sgimeno: Backport for [[gerrit:1083870|Enable electionclerk user group on enwiki (T378287)]], [[gerrit:1154369|core-Permissions:Restrict editing on cawikimedia to autoconfirmed only (T396178)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-06-10T13:34:20Z] <sgimeno@deploy1003> Finished scap sync-world: Backport for [[gerrit:1083870|Enable electionclerk user group on enwiki (T378287)]], [[gerrit:1154369|core-Permissions:Restrict editing on cawikimedia to autoconfirmed only (T396178)]] (duration: 11m 22s)

Special:SecurePollLog is erroring out: T396483.