Given that "Miraheze sysadmins" includes a WMF globally banned user, I don't see why we would do this.

In T270203#6693084, @Legoktm wrote:

Given that "Miraheze sysadmins" includes a WMF globally banned user, I don't see why we would do this.

Obviously, they don't have a Wikimedia Phabricator account so they wouldn't be affected by this. The intent is only to allow easier adding for tasks we file which our own sysadmins will have access to our downstream security reports anyway.

All Miraheze sysadmins have NDAs as part of their role.

With the Foundation? How does this work?

With the caveat that Phabricator isn't an area with which I'm super familiar, I'm not sure why Miraheze would be using the Wikimedia Phabricator system for this stuff anyways?

In T270203#6693161, @jrbs wrote:

All Miraheze sysadmins have NDAs as part of their role.

With the Foundation? How does this work?

Just with us. It would cover security issues reported to or found by us and filed upstream.

With the caveat that Phabricator isn't an area with which I'm super familiar, I'm not sure why Miraheze would be using the Wikimedia Phabricator system for this stuff anyways?

I mean for things like security issues with MediaWiki that we find. Like T270145 and T267985

What would be the exact and complete workflow of maintaining membership in this acl tag, and which steps would you perform when creating a Phab task here which would somehow use that acl tag?

In T270203#6693186, @RhinosF1 wrote:

Just with us. It would cover security issues reported to or found by us and filed upstream.

In my non-legal opinion I'm not sure this is really good enough for our purposes.

I mean for things like security issues with MediaWiki that we find. Like T270145 and T267985

Again I'm not extremely familiar with how security bugs are generally handled, but I believe those who need to have access to those tasks would be granted that access especially if they discovered the issue. I think that's how it currently works, though more than happy to let someone who actually knows what they're talking about to hop in ;)

In T270203#6693194, @Aklapper wrote:

What would be the exact and complete workflow of maintaining membership in this acl tag?

It would be added as part of our on and off boarding for sysadmins which would mean when they join we'd ask if they want access and what their phab account is and then when/if they leave we'd revoke access.

and which steps would you perform when creating a Phab task here which would somehow use that acl tag?

My understanding is that you can just add the project as a subscriber and that would give access or there is the custom form allowing you to set an ACL (New Task (Advanced)) so we could do it by adjusting that when we file the task.

In T270203#6693195, @jrbs wrote:

In my non-legal opinion I'm not sure this is really good enough for our purposes.

Our standard procedure now as seen in the tasks I gave is just to manually add our sysadmins anyway when we file a security bug if they ask for access so it doesn't really affect what they can see.

Can we get a list of proposed users to be added to this acl?

Can we also get a list of example/reference of (recent, open and closed) tasks that this would've been applicable/useful if this ACL existed?

T270145 and T267985 are the most recent two and me, @Reception123, @Southparkfan, @Paladox, @Zppix, @NDKilla and @Universal_Omega

@RhinosF1 - The Security-Team had a chat about this today. We don't really have a problem with people creating custom ACLs for various projects and workflows within Phabricator, but we wouldn't want those to inherit as sub-projects from acl*security. For now, given the relatively small number of recent related tasks and users, we'd recommend sticking with the current security issue reporting process while being more proactive about adding relevant users as subscribers to various tasks as needed. Any subscriber to a security issue should be able to add other Phabricator users (and they themselves will be added after reporting the security issue via the standard Phabricator form). The Security-Team can also review and add relevant users to these tasks if needed, and you can message us on IRC, Phabricator, email, etc. to do so.