The Developer account <-> SUL user mappings that Bitu is now maintaining in LDAP are likely to be of help with this project. Striker has a legacy feature that needs to be updated to also use LDAP for storage (T148048: Store Wikimedia unified account name (SUL) in LDAP directory). A third source of these mappings is right here in Phabricator where a given account can be linked to either a SUL account, a Developer account, or both.

Tool-gitlab-account-approval is attempting to leverage existing allow lists from Gerrit, Phabricator, and Toolforge to establish trust in GitLab. My involvement with that project is part of why I started thinking about this general issue and its complexities.

I am removing Gerrit and Continuous-Integration-Config since this task is not immediate actionable for any of those projects and that requires preliminary work above those specific projects.

In T364516#9798495, @hashar wrote:

I am removing Gerrit and Continuous-Integration-Config since this task is not immediate actionable for any of those projects and that requires preliminary work above those specific projects.

The task is not immediately actionable to any single system that currently maintains a trusted user list. Where should we park it to actually get a chance of being triaged by a team and assigned so resources someday?

FYI, Patch Demo also uses Zuul's email allow list: https://gitlab.wikimedia.org/repos/test-platform/catalyst/patchdemo/-/blob/6be53806f325f2724d2865ad5057ca707206c82e/includes.php#L851

If that list goes away or its format changes, that will need to be updated too.

I guess an implicit question here is -- are each of these 'groups of trust' basically on the same level as each other? (And/or, phrased another way: would everyone trusted to be a Toolforge member also be trusted to edit Phabricator projects? / would everyone trusted to edit Phab projects also be trusted to not host malware on Patch Demo?)

I suppose another implicit question might be -- what happens if it's determined that someone needs to be removed from one of these lists/groups? At the moment, if (as a random hypothetical example) a member of Trusted-Contributors was being unintentionally disruptive with their edits to Phab projects, that could be remedied by just removing them from that Phab group; and such an action wouldn't affect (e.g.) that person's Toolforge membership. However, if there was a single source of truth for a 'trusted user' list, it seems like the only remedy might then be to remove them from that centralised list -- which would then also remove all other 'trusted user' privileges from their accounts on other Wikimedia development systems (incl., e.g., their Toolforge membership).

I'm asking these questions in the context of having filed T412607: Ensure that auto-created Phabricator projects for Toolforge tools are always editable by that tool's maintainers, and in the context of that task's commenters currently favouring an approach of having Striker automatically add Toolforge members to the Phabricator Trusted-Contributors group (either at the time of it creating a tool's Phab project, or at the time of a Toolforge access request being approved). AFAICS, this approach would pretty tightly tie Trusted-Contributors group membership to Toolforge membership; especially as - to my knowledge - there's not a(n easy) way to use the Phabricator API to find out whether someone has been removed as a Phab project's member at some point in the past.

(FWIW, these are genuine questions, and I'm not trying to imply anything with them in any direction :))

Toolforge is a higher level of trust that Trusted-Contributors IIRC.

I think the rest (GitLab account approved, Zuul allowlist, Gerrit trusted-contributors group, Trusted-Contributors) are all roughly equivalent to each other.

a member of Trusted-Contributors was being unintentionally disruptive with their edits to Phab projects, that could be remedied by just removing them from that Phab group

Please note anyone in trusted contributor group can remove anyone and once it is removed anyone in trusted contributor can add that user back. So if this is used frequently it will causes much drama. Previously @Aklapper removed a user from that group and I complained at https://www.mediawiki.org/wiki/User_talk:AKlapper_(WMF)#Trusted-Contributors. In that case, I don't see the issue is severe enough to remove from trust list, and if it is, removing it to trust list is not an efficient action since it can be added back by any trusted contributor (and there are no clear guide for other user whether and when they can do so).

If it is a concern that some user does not contribute properly but not yet needed to be disabled outright (I argue Faster_than_Thunder would be a recent case), potentially we can create an "Untrusted contributors" group (negates Trusted Contributors), and/or "Banned from maniphest" group. Phabricator technically supports that, but I believe many people will oppose since it will make permission structure of Wikimedia Phabricator more complex.