To help folks reason about these choices a bit:

• Anyone in acl*sre-team is also in acl*security because the former is a subproject of the latter.
  • This means that anyone who can read an acl*sre-team restricted task can also read an acl*security restricted task. The inverse is however not true.
• acl*sre-team is a prod root only access group. "This is an ACL Group and should ONLY contain members of the SRE/operations team. This includes operations roles in fr-ops and cloud."
  • The group has no direct relation to either acl*security or WMF-NDA
• acl*security is the collection of users and groups that are allowed to see tasks created using the Report Security Issue form. Existing public tasks can be converted to acl*security restricted tasks via the Protect as security issue link in the right hand menu of the task detail screen.
• WMF-NDA is a group of users known to have signed an NDA with the WMF. Typically WMF-NDA restricted tasks are created using the New Private Task form.

My personal choice would be acl*security. Tasks with that protection level have an existing review workflow that can be used to convert from a Security Issue to a public task when appropriate. That workflow also recognizes that some tasks should be marked as PermanentlyPrivate because of data that is contained in the task's description or comments (typically PII like IP addresses or email addresses).

In T389664#10663848, @bd808 wrote:

To help folks reason about these choices a bit:

• Anyone in acl*sre-team is also in acl*security because the former is a subproject of the latter.
  • This means that anyone who can read an acl*sre-team restricted task can also read an acl*security restricted task. The inverse is however not true.
• WMF-NDA is a separate user hierarchy. Some of the 377 members of WMF-NDA are also acl*security (and possibly acl*sre-team) members, but there is no guaranteed relationship. WMF-NDA is neither a strict superset or subset of acl*security.

Typically WMF-NDA restricted tasks are created using the New Private Task form.

Typically acl*security restricted tasks are created using the Report Security Issue form. Existing public tasks can be converted to acl*security restricted tasks via the Protect as security issue link in the right hand menu of the task detail screen.

Thanks @bd808, I think this clarifies things quite a bit.

My vote would be for acl*security. I'm not sure who needs to weigh in on this, but the choice of acl*sre-team was a) one of safety, and b) a general unwillingness for folks to weigh in on what the right access should be, so I don't think we need to let much time elapse before moving forward (it feels like acl*sre-team is objectively better).

acl*sre-team != acl*security_sre. acl*sre-team does not appear on https://phabricator.wikimedia.org/project/subprojects/30/ as a subproject of acl*security (aren't phab ACLs fun?)

In T389664#10664409, @AntiCompositeNumber wrote:

acl*sre-team != acl*security_sre. acl*sre-team does not appear on https://phabricator.wikimedia.org/project/subprojects/30/ as a subproject of acl*security (aren't phab ACLs fun?)

Ugh. Thanks for pointing out that mistake by me ACN. That makes acl*sre-team even less useful as it is a separate hierarchy and currently documented as "This is an ACL Group and should ONLY contain members of the SRE/operations team. This includes operations roles in fr-ops and cloud." That would mean these tasks are all prod root only and not visible to any application team members, community experts, or non-root management at all.

Is there anyone that thinks that acl*security is a worse choice of default visibility?

Change #1131479 had a related patch set uploaded (by Eevans; author: Eevans):

[operations/puppet@production] corto: use #acl*security for new incidents

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

+1 on changing to acl*security

Change #1131479 merged by Eevans:

[operations/puppet@production] corto: use #acl*security for new incidents

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

In T389664#10696041, @Eevans wrote:

Change reverted because the bot needs to be part of the acl*security project in order to create new issues.

Opened: T390627: Security Issue Access Request for corto (an IRC bot)

Change #1135478 had a related patch set uploaded (by Eevans; author: Eevans):

[operations/puppet@production] corto: use #acl*security for new incidents

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

Change #1135478 merged by Eevans:

[operations/puppet@production] corto: use #acl*security for new incidents

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