FTR, I've already performed the removals. That section mostly serves as a notification of 2023 steward departures.

@Urbanecm do you need the security team to take any action on this? I can add if needed, but it not I will untag the security team.

In T331492#8677242, @Mstyles wrote:

@Urbanecm do you need the security team to take any action on this? I can add if needed, but it not I will untag the security team.

Hi, I need the Security team to add the newly-elected stewards to the ACL group (acl*security_steward description says Security-Team needs to approve each addition). So, I'd like to ask for that approval :). Also, I can't check the 2FA requirement myself, so that also needs some assistance.

In T331492#8677279, @Urbanecm wrote:

Hi, I need the Security team to add the newly-elected stewards to the ACL group (acl*security_steward description says Security-Team needs to approve each addition).

Hmm, that's weird. We don't require that for other security ACLs. I think the idea of self-management for those (members performing these updates) was built into that architecture, but I guess that's another matter. I mean, there's nothing stopping members from managing those ACLs AFAIK. Anyhow, the Security-Team approves any verified, newly-elected stewards for Phabricator security issue access, assuming they have 2fa enabled. Do you still need us to add these members after 2fa verification or would you like to do that?

So, I'd like to ask for that approval :). Also, I can't check the 2FA requirement myself, so that also needs some assistance.

Neither can most folks on the Security-Team. So @Reedy, @Aklapper or a similarly-privileged user would need to assist with that.

In T331492#8677350, @sbassett wrote:

In T331492#8677279, @Urbanecm wrote:

Hi, I need the Security team to add the newly-elected stewards to the ACL group (acl*security_steward description says Security-Team needs to approve each addition).

Hmm, that's weird. We don't require that for other security ACLs. I think the idea of self-management for those (members performing these updates) was built into that architecture, but I guess that's another matter.

No objection if that gets changed, I was just following the description :).

Anyhow, the Security-Team approves any verified, newly-elected stewards for Phabricator security issue access, assuming they have 2fa enabled.

Can you clarify what "verified" means in this context? Does that mean simply verifying that the Phabricator accounts actually belong to a duly elected steward? Or some other kind of verification that needs to happen?

Also, does this approval extend to standing stewards who are not yet in the ACL? In another, if a sitting steward asks for security issue access (outside of the election time), does the approval above apply to their addition? Or would that need to be approved individually?

Do you still need us to add these members after 2fa verification or would you like to do that?

It feels easier if a Phab admin adds them while checking 2FA, but considering the clear approval above for new stewards, I'd feel comfortable doing that myself once 2FA's confirmed.

In T331492#8677457, @Urbanecm wrote:

Can you clarify what "verified" means in this context? Does that mean simply verifying that the Phabricator accounts actually belong to a duly elected steward? Or some other kind of verification that needs to happen?

Just that the Security-Team approves this task. And that, yes, we assume that you and/or other stewards have verified the steward => Phab account relationship.

Also, does this approval extend to standing stewards who are not yet in the ACL? In another, if a sitting steward asks for security issue access (outside of the election time), does the approval above apply to their addition? Or would that need to be approved individually?

Given the current policy with the Phab policy description, I suppose that should be a separate task, just to officially track it and approve it. In practice I don't think that, for any reason, the Security-Team would likely object to any current steward having Phab security access.

It feels easier if a Phab admin adds them while checking 2FA, but considering the clear approval above for new stewards, I'd feel comfortable doing that myself once 2FA's confirmed.

Ok, hopefully one stops by soon :)

In T331492#8681199, @sbassett wrote:

In T331492#8677457, @Urbanecm wrote:

Can you clarify what "verified" means in this context? Does that mean simply verifying that the Phabricator accounts actually belong to a duly elected steward? Or some other kind of verification that needs to happen?

Just that the Security-Team approves this task. And that, yes, we assume that you and/or other stewards have verified the steward => Phab account relationship.

So, in that case, the description of the project's actually correct, as Security-Team approval is needed each time the ACL membership changes (in bulk after elections, or individually if a need arises during the term), and there's actually nothing to do differently than I did here? Or am I missing something?

In T331492#8683061, @Urbanecm wrote:

So, in that case, the description of the project's actually correct, as Security-Team approval is needed each time the ACL membership changes (in bulk after elections, or individually if a need arises during the term), and there's actually nothing to do differently than I did here? Or am I missing something?

It is a close reading of what is currently stated within that policy's description, yes. What you are likely missing is:

1. When the various acl*security_ policies were redone about 3 years ago now, the bulk of that work was approved by, completed and mostly managed by two people who no longer work for the WMF, namely Chase and John. And not every aspect of these processes was formally documented outside of what exists within various Phab descriptions. So the Security-Team does not have any formal, internal documentation about these processes, whether they were appropriate as they existed then or are appropriate as they exist now.
2. When the various acl*security_ policies were created, one of the key, internal goals for them was to push off much of their maintenance to the trusted groups of members of those policies. This is part of a broader goal of the Security-Team to create as many self-service tools, processes and automation for anything security-related across the Wikimedia universe, as we are a small team and it would be impossible for us to manually manage every possible security concern. Again, this likely wasn't communicated very well to folks who must deal with the various acl*security_ policies on a day-to-day basis, but I can guarantee you that it was absolutely a hope and assumption of the Security-Team.

@Aklapper Could you please confirm if all three of us have 2FA enabled? Thanks :)

Any Phab admin could check (the Security team also has Phab admin members). :)

In T331492#8687004, @Aklapper wrote:

Any Phab admin could check (the Security team also has Phab admin members). :)

I think just @Reedy at this time. Probably wouldn't hurt to have at least one additional backup though, from the Security-Team.

In T331492#8685878, @Superpes15 wrote:

@Aklapper Could you please confirm if all three of us have 2FA enabled? Thanks :)

{{confirmed}} :)

In T331492#8677350, @sbassett wrote:

In T331492#8677279, @Urbanecm wrote:

Hi, I need the Security team to add the newly-elected stewards to the ACL group (acl*security_steward description says Security-Team needs to approve each addition).

Hmm, that's weird. We don't require that for other security ACLs. I think the idea of self-management for those (members performing these updates) was built into that architecture, but I guess that's another matter. I mean, there's nothing stopping members from managing those ACLs AFAIK. Anyhow, the Security-Team approves any verified, newly-elected stewards for Phabricator security issue access, assuming they have 2fa enabled.

Should the description be updated based on this? That as long as an admin confirms 2FA status, the group can be self-managed by stewards?

In T331492#8689467, @Legoktm wrote:

Hmm, that's weird. We don't require that for other security ACLs. I think the idea of self-management for those (members performing these updates) was built into that architecture, but I guess that's another matter. I mean, there's nothing stopping members from managing those ACLs AFAIK. Anyhow, the Security-Team approves any verified, newly-elected stewards for Phabricator security issue access, assuming they have 2fa enabled.

Should the description be updated based on this? That as long as an admin confirms 2FA status, the group can be self-managed by stewards?

I'm fine with making that change and owning it for the Security-Team, provided @Urbanecm or any other stewards do not have any objections.

I'm fine with making that change and owning it for the Security-Team, provided @Urbanecm or any other stewards do not have any objections.

Fine with me (and I believe with other stewards as well).

Ok, I've revised the policy description (the warning, specifically): https://phabricator.wikimedia.org/project/manage/4570/. Let me know if there are any additional concerns.