Security is for security issues, I believe access requests should be in Security-Team instead.

I approve this as the manager for @Tchanders.

@sbassett You can see them here: https://phabricator.wikimedia.org/search/query/Wq6yQbXrr0Nw/#R
Is this a new process for Security access? Thalia is a long time WMF staff member, if that wasn't clear already.

@Niharika - Yes. We've lately been trying to limit access even further to Security to those who absolutely need it (as opposed to just kind of want it.) Given @Tchanders's role on the AH team and the tasks you've provided, I think they probably meet these requirements, but again, we'll confirm this at our Security-Team check-in next week.

@sbassett in that case, I just want to make sure we add to the list the fact that Anti Harassment's Tool team's work touches on blocking tools, which inherently tend to be Security tickets if any bug happens there.
Our upcoming work will involve CheckUser, which, again, almost exclusively has bugs in the security realm. For us, this is not just a matter of this being useful, but a pretty crucial part of the work, in case bugs happen in the part of the code we actively work on.

Thanks!

@sbassett I don't fully understand the reasons behind such extreme restrictions. Engineers working with WMF teams should have this access. If I (or other people with access) were not around to add @Tchanders and @dom_walden to a critical security ticket, we would have a major UBN on our hands.

@Niharika - I think you've illustrated part of the point here: that individuals can be added to Security -protected tasks on a case-by-case basis, as opposed to the entire collection of previous and future tasks. As noted, anyone with Security access can do this, when a demonstrated need arises. The higher bar is merely an effort to more tightly control access to Security tasks, i.e. has the requester only ever worked on a couple of protected tasks or have they worked on several with a likely need for access to future tasks (and potentially older [and very sensitive] tasks, e.g. PermanentlyPrivate).

@sbassett You're missing the point that it wastes valuable time in the face of a security bug to go around (where? IRC?), find someone who has access and ask them to add you. Not to mention that it feels kinda humiliating (at least to me personally) to have to ask someone (who is somehow more "trusted") to add you in.

I will remind everyone that we're talking about a WMF employee here.

I can understand high scrutiny in general, but I don't see a how adding an employee to the access group is not something -- honestly -- that we do automatically. If there ever is a reason that a specific employee of the Foundation should not be exposed to security tickets (current or old) then we have a bigger issue about whether or not they should be employed to begin with.

@sbassett I understand that you're following the (new'ish?) process, and this isn't meant to be a pile on or to blame you -- but I do think that when you, at the Security team, talk about this, you should discuss the more general application of this new process when it comes, specifically, to a Wikimedia Engineering employee, who needs access to fix unbreak-now and security-delicate tasks, basically as part of their job description, and who already signed basically a form of an NDA by merely signing the employment contract.

In T231608#5455246, @Niharika wrote:

(where? IRC?)

Often times, yes, though there are other channels (email, mobile devices, etc.) where people can be found. And members of the Security-Team (who all have Security access) are more than happy to assist in ensuring individuals have access to relevant protected tasks. I'm trying to think of situations where an individual would need access to a High/UBN Security task where they were not the creator of the task (and therefore automatically subscribed) or that the task had such a status but was not being actively worked upon by one or more individuals who would be available to quickly grant access.

Not to mention that it feels kinda humiliating (at least to me personally) to have to ask someone (who is somehow more "trusted") to add you in.

This is fast becoming a religious argument, though I'd contend that without layers of trust, it doesn't make much sense to have any ACLs within Phabricator at all. The #security-team are the current stewards of #security access AIUI. I'm sure a conversation could be had if a different set of policies or process ownership would seem appropriate.

In T231608#5455253, @Mooeypoo wrote:

I will remind everyone that we're talking about a WMF employee here.

I can understand high scrutiny in general, but I don't see a how adding an employee to the access group is not something -- honestly -- that we do automatically. If there ever is a reason that a specific employee of the Foundation should not be exposed to security tickets (current or old) then we have a bigger issue about whether or not they should be employed to begin with.

WMF employee accounts can certainly become compromised. And we've said no in the past (T218588). This is really about reducing attack surfaces as much as possible while limiting access to extremely sensitive information if a compelling case is not made.

@sbassett I understand that you're following the (new'ish?) process, and this isn't meant to be a pile on or to blame you -- but I do think that when you, at the Security team, talk about this, you should discuss the more general application of this new process when it comes, specifically, to a Wikimedia Engineering employee, who needs access to fix unbreak-now and security-delicate tasks, basically as part of their job description, and who already signed basically a form of an NDA by merely signing the employment contract.

For these kinds of requests, where there is a very obvious, demonstrated need, I would be shocked if Security access were not approved. As previously stated, IMO, @Tchanders meets these requirements, but as this is a team process with final approval resting with our director, I cannot make that call myself.

Fair enough.

As an aside, I disagree with some of the process decisions here, but I don't know if this ticket is the best way to confront them, and I also don't expect you to be the one facing our consternation ;) At this point, it might be better if we find the right route to check into where we can give feedback about the process and see if we can discuss its implications.

Thank you for responding, and we'll await the team's actions on this.

Thanks everyone.

@sbassett Thanks for your help here. While there was some back and forth, I had a really productive meeting with @JBennett yesterday about your team's plans for Phab task tagging. I'm excited about the clarity and flexibility that might come out of it.

I appreciate your following up here and helping us understand the changes that are happening.

Did anything ever come of the "proposals and/or policy updates available for that soon"? I've had a few security tasks I can't see lately, so I'm wondering where we are on the whole issue.

In T231608#7437331, @DLynch wrote:

Did anything ever come of the "proposals and/or policy updates available for that soon"? I've had a few security tasks I can't see lately, so I'm wondering where we are on the whole issue.

There isn't really any update, but IMO the push for more aggressively controlling this variety of access on our part has simmered down a bit. If you're an active Wikimedia developer and have a few good use-cases for needing Phabricator security access (I know you are/have both) then you can file a new task requesting access and @Dsharpe should be able to help you out.