Page MenuHomePhabricator

Create acl*stewards
Closed, ResolvedPublic

Description

It is not infrequent to see stewards reporting bugs here. Some of those are private bugs for a variety of reasons such as security issues or other private stuff. Once those tasks are created, we add as suscribers a couple of users who might be interested or who cooperated in discovering the bug and reporting it, but at the end we end up having to add more subscribers because of the interest in knowing the process of the bug or for stewards to know the behaviour of the issue to avoid problems in their daily work.

A security or private bug that we spot should is no secret for the rest of the team, in fact we need to know them to avoid private data leaks and the like, and since adding more than 30 subscribers to each private task we've reported is overkill, I'd like to propose creating a group which contains current stewards, for all of us be able to look at the private bugs we report, without having to guess who was the author or is subscribed, then ask him/her to add us to the task.

If I understood the process correctly, if we add the project to the subscribers field, all members of that group will get access to the task containing it.

Project management and membership of the project should be restricted to current stewards, and maybe some WMF staff from the Support and Safety (SuSa) dept, such as @Jalexander, @Kalliope or @Mdennis-WMF

I've checked with my fellow stewards on our mailing list and received no opinion against. As project-creator I can create the project myself, but project guidelines requires ACL projects to be proposed and discussed before its creation.

Note that this is very different from Stewards-and-global-tools, where we track public tasks of bugs found on a variety of tasks that might be of interest of stewards, swmt members, administrators, checkusers, etc. However I wonder if what I propose here can be done via a subproject of that subproject too.

Best regards.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Restricted Application added subscribers: JEumerus, Aklapper. · View Herald TranscriptApr 4 2016, 4:12 PM

This needs to be done by an admin, because "normal" project creators can't adjust policys.

MarcoAurelio removed MarcoAurelio as the assignee of this task.Apr 4 2016, 4:39 PM
MarcoAurelio added a project: Phabricator.

This needs to be done by an admin, because "normal" project creators can't adjust policys.

Thanks for the info. I'm adding Phabricator then and putting the task up for grabs since I can't obviously fullfil the task.

Restricted Application added a subscriber: scfc. · View Herald TranscriptApr 4 2016, 4:39 PM
Krenair added a subscriber: Krenair.EditedApr 4 2016, 4:45 PM

If I understood the process correctly, if we add the project to the subscribers field, all members of that group will get access to the task containing it.

That depends on the task visibility policy. It also spams all project members with email about the issue.

Also, people (e.g. stewards) with individual-task access to security information should not be sharing it like this (those with complete security access already can't do this), they could end up being removed from current and future security tasks.

MarcoAurelio added a comment.EditedApr 4 2016, 5:12 PM

If I understood the process correctly, if we add the project to the subscribers field, all members of that group will get access to the task containing it.

That depends on the task visibility policy. It also spams all project members with email about the issue.

I see. And will it work if added as project in the task itself?. Since Spaces were introduced I'm a bit lost...

Also, people (e.g. stewards) with individual-task access to security information should not be sharing it like this (those with complete security access already can't do this), they could end up being removed from current and future security tasks.

Hmm, well, we ain't talking about posting on Phabricator very sensitive data such as IP addresses, email addresses or other information such as raw DB logs, etc, and as for myself I try to avoid posting that kind of data (users with the appropriate rights can access it if needed via the tools or the DB as they think it's most appropriate). As you can see from our past reports, it's mostly about private bugs which are nonpublic to avoid malicious users noticing it and exploiting the bug while still in resolution, mostly for CentralAuth and CheckUser extension or other MediaWiki bugs. In any case, if this is going to be a security issue itself, we would like to avoid that. We remain sincerely yours.

If I understood the process correctly, if we add the project to the subscribers field, all members of that group will get access to the task containing it.

That depends on the task visibility policy. It also spams all project members with email about the issue.

I see. And will it work if added as project in the task itself?. Since Spaces were introduced I'm a bit lost...

No, the project list cannot change visibility. You'll have to get people in one of the ACL admin projects (for example, Security) to change each task you want to add the project to the visibility policy, so that all members can view.

Also, people (e.g. stewards) with individual-task access to security information should not be sharing it like this (those with complete security access already can't do this), they could end up being removed from current and future security tasks.

Hmm, well, we ain't talking about posting on Phabricator very sensitive data such as IP addresses, email addresses or other information such as raw DB logs, etc, and as for myself I try to avoid posting that kind of data (users with the appropriate rights can access it if needed via the tools or the DB as they think it's most appropriate). As you can see from our past reports, it's mostly about private bugs which are nonpublic to avoid malicious users noticing it and exploiting the bug while still in resolution, mostly for CentralAuth and CheckUser extension or other MediaWiki bugs. In any case, if this is going to be a security issue itself, we would like to avoid that. We remain sincerely yours.

I suppose I wasn't very clear, we seem to misunderstand... Certain steward(s) have access to information (whether that's user private data or typically-confidential things like software security vulnerabilities) far beyond what should be shared with all stewards. Yet you imply that stewards share information about all private tasks (that might not even be relevant to the stewards in general, e.g. it just concerns one) amongst one another.

I think my language was not clear, sorry. When we encounter a bug that affects our work as a team, we inform the rest of the team with a short summary of what's happening, and if we already reported the issue, a link to the Phabricator task. That's useful to doublecheck if it's happening just to one user, or more, and if the bug is confirmed. At least that's how we've been working for years now. That's not to say that we share details of each and every private bug we create, but just for things that ought to be known or would be convenient for stewards to have access to. For example, I think on tasks such as T37770, T34218, T124606 or T125132 (T31508 was an extreme, not sure if I'd have added any more subs.). If this practice displeases security folks, we can look forward discontinuing it.

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptApr 26 2016, 7:05 PM
Luke081515 triaged this task as Low priority.May 3 2016, 9:47 PM

For example T136418 would be a good example too for this acl. In this case it would be enough to add this ACL as CC.

Danny_B added a subscriber: Danny_B.Aug 9 2016, 5:54 PM

For example T136418 would be a good example too for this acl. In this case it would be enough to add this ACL as CC.

ACLs should not be subscribers.

greg added a subscriber: greg.Aug 10 2016, 4:17 PM

For example T136418 would be a good example too for this acl. In this case it would be enough to add this ACL as CC.

ACLs should not be subscribers.

Why not? It's a way of contacting them without adding a task to their backlog. After someone from that acl group sees the task they can choose to remove their acl subscription and subscribe themselves (or whoever else from that acl that makes sense).

T148110 is another example. Maybe this can be created as a subgroup of Policy-Admins

No, that would give them the ability to change policies on things.

This comment was removed by Krenair.

Currently:

Anyone who is a member of Security can already add the Stewards-and-global-tools tag whenever applicable to a Security task.

Members of Stewards-and-global-tools can get notifications about Stewards-and-global-tools task changes. But if you are only a member of Stewards-and-global-tools and you are not a member of Security you will not get notifications about a Stewards-and-global-tools task change if that task is also in Security.

You can also explicitly search for open tasks associated to both the Security project tag && the Stewards-and-global-tools. Only if you a member of Security you will see more than zero results.

Future?:

I'm wondering if we could have those stewards interested in following relevant bug reports have access to (access restricted) Security tasks.
Any stewards who are interested would have to follow https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Policy/Access_To_Security_Issues (basically: sign an NDA and get an okay) though.

Does that sound feasible? So far I don't see a convincing reason why to have another abstraction layer by creating a project like acl*stewards, but maybe I completely missed something?

(No Phabricator Spaces involved.)

But if you are only a member of Stewards-and-global-tools and you are not a member of Security you will not get notifications about a Stewards-and-global-tools task change if that task is also in Security.

Unless you are able to read the task through some other means, or it is a publicly viewable Security task.

You can also explicitly search for open tasks associated to both the Security project tag && the Stewards-and-global-tools. Only if you a member of Security you will see more than zero results.

That's not strictly true since not all Security tasks are hidden.

The problem would still be the visibility, because even if this policy project is created, we still need someone with the appropriate rights to modify the "Visible To" field in the bug to add the project, so the members of the project could get access automatically. And since I guess that gaining access to #acl*phabricator (hmm, can't be linked?) or even creating a acl*stewards_policy_admins subproject of Policy-Admins is rather unlikely, I'm not sure if this is going to be approved. Maybe we should stick to the old way of doing things and adding some people as CC in case they're interested in following the hidden bug.

MarcoAurelio added a comment.EditedNov 8 2016, 5:02 PM

Another option: instead of a acl*stewards we can create a #stewards subproject inside Stewards-and-global-tools. That subproject would contain only current stewards and should only be edittable by project members and administrators. That'd be some sort of a safe list for us and could be added to "Visible To" in some cases, and also for other future projects we'd like to undertake (such a closed conpherence rooms, etc.). That said, I'm not sure if that subproject should still be acl* or not.

If it's restricted like that, yes, it needs acl*

MarcoAurelio closed this task as Declined.Nov 8 2016, 5:13 PM
MarcoAurelio moved this task from Untriaged to Closed on the Stewards-and-global-tools board.

Thanks. So to make this work, we need one project with the members and another project with maybe less members allowed to alter the visibility of tasks; or have anyone with appropriate rights to alter the visibility of the task to add the group. Being realistic, I don't think this is going to happen, then.

(Krenair is correct in T131766#2779887; thanks!)

The problem would still be the visibility, because even if this policy project is created

In my previous comment I proposed not to create another policy project as I do not see any advantage. Because if you want to access a Security restricted task, you need to have an NDA in place anyway. No "changes of visibility" needed or proposed in my last comment.

In my previous comment I proposed not to create another policy project as I do not see any advantage. Because if you want to access a Security restricted task, you need to have an NDA in place anyway. No "changes of visibility" needed or proposed in my last comment.

@Aklapper I'm sure it was me who was not clear here :-) I was just describing what I thought would be the steps required to make this happen (an acl* group + have someone add the group to the "visibility" field of the task -or- have a subset of us being policy-admins; neither of that two things were likely to happen as things stand now). I was not proposing that we're given access to all Security tasks. Thanks.

jeremyb added a subscriber: jeremyb.Nov 8 2016, 6:15 PM

And now I have to correct myself, sorry:
When adding a user to an access-restricted Security task, the user can view and edit that task even though not being a member of Security. (In general, the "Subscribers" field allows both adding users and projects.)

So if there was an ACL project for Stewards (with a restricted Join policy) that could technically work, if I understand everything correctly.
Which turns this into a social question IMO, whether that's okay with WMF's security folks. (For those who can access it, T127719 comes to my mind.)

In hindsight, describing a problem ("Find a way to allow the group of stewards access specific access-restricted Security tasks"?) instead of a solution ("Create acl*stewards") might have helped me understand this better. :D Sorry again...

MarcoAurelio added a comment.EditedNov 8 2016, 6:38 PM

In hindsight, describing a problem ("Find a way to allow the group of stewards access specific access-restricted Security tasks"?) instead of a solution ("Create acl*stewards") might have helped me understand this better. :D Sorry again...

Yes, that was the idea.

Now you told me:

[me asking] andre__: wrt acl*: yes, but then we'd need someone able to add that group to the "Visible To" field of the relevant task, which requires somebody from Security, acl*phabricator or Policy-Admins I think (although I'm lost with this new policies/spaces/groups)
[you responding] mafk: Noone would need to edit a "Visible To" field.

I think that's not correct, unless now adding a project as subscriber gives the project members permissions to access a restricted task. I was told that's not how things were suposed to work, and that someone should alter the visibility of the task adding the project in the "Visible To" field.

Again, if the info I got is wrong, sorry.

mmodell added a subscriber: mmodell.Nov 8 2016, 6:44 PM

I think that's not correct, unless now adding a project as subscriber gives the project members permissions to access a restricted task. I was told that's not how things were suposed to work, and that someone should alter the visibility of the task adding the project in the "Visible To" field.
Again, if the info I got is wrong, sorry.

I think you can subscribe a project and indeed it should allow all members to see the task. I'll have to test it.

@MarcoAurelio, @Aklapper: I can confirm that subscribing a project allows all members of the project to view the task, as long as 'subscribers' is included in the view policy.

@MarcoAurelio, @Aklapper: I can confirm that subscribing a project allows all members of the project to view the task, as long as 'subscribers' is included in the view policy.

@mmodell Thanks. Can you confirm if that's the case for T125132, for example? (I mean, is the view policy in that task configured to allow a group as subscriber, for example)

That said, isn't it a bit "dangerous" to allow projects to view if they're subscribers? I mean, if there's a mistake and in a private bug we erroneusly add a tag in the subscribers field instead of the tags field?

Regards.

@MarcoAurelio: Indeed, subscribers can view T125132. I don't know if I would call it dangerous but it certainly does seem somewhat error-prone.

In practice, I haven't seen anyone accidentally subscribe a project to a private task. The tags field is locked on https://phabricator.wikimedia.org/maniphest/task/edit/form/2/ and tags are typically added from the 'Take action' form rather than the task submission form.

Jalexander reopened this task as Open.Jan 29 2017, 12:08 AM
Jalexander claimed this task.

I'm going to reopen this rather then creating a new one (or not) in order to allow people to wave their hands and call me crazy as needed given that it was previously declined. I'd like to (and currently plan to barring good reason not to) create this acl in order to allow it to be added as managers on the Confidentiality Agreements (the only way they're able to see signatures) so that they're able to quickly and efficiently process requests for access on meta without waiting on staff.

MarcoAurelio added subscribers: Slaporte, Jrogers-WMF.

@Jalexander If we're given the ability to see the signatures of Nonpublic-Information-Access-Policy that should be clearly mentioned elsewhere. If approved, we should also be given instructions on how and when to consider a signature as valid (ie: if the MediaWiki account is linked to the Phabricator account, whether other things should be verified, etc.). That said, I'd personally prefer that the Wikimedia Foundation still be tasked with adding and removing people from that Board.

Overall I proposed and supportted the creation of this acl* for other questions here in Phabricator, but I'm not sure I agree with managing the general NDA board (since adding a name there means he's legally eligible to hold advanced rights, and I don't think many of us would like to take that liability in case of a false signature --and we've got a recent case--).

On the other hand, as acl*otrs-admins myself I already have access to and approve access to Wikimedia OTRS system, but I feel that the general access policy NDA is more sensitive. Willing to be convinced otherwise and something that WMF-Legal should carefully consider I think.

Regards.

Teles added a subscriber: Teles.Feb 15 2017, 11:05 AM
jrbs added a subscriber: jrbs.Apr 12 2017, 7:04 PM

@zhuyifei1999: "I wish we have an acl*stewards access list on phabricator".

I think that there are cases where such an acl* would've been useful and we can look to expand or decrease their scope later but IMHO the creation of the acl* is justified so please create acl*stewards with edit/join policies set to members of the group, and add me as members so I can take care of adding further members lately. Thanks.

MarcoAurelio closed this task as Resolved.Jun 28 2017, 11:54 AM
MarcoAurelio reassigned this task from Jalexander to mmodell.

@mmodell Thanks! I've added my fellows over there. I consider this task as resolved.

H229 won't let me add @mmodell as assignee w/o adding that tag again and again.

Aklapper reassigned this task from Jalexander to mmodell.Jun 28 2017, 12:33 PM

So leave the tag. :)

The Release-Engineering-Team (Kanban) tag is used to track what the release engineering team has been working on, please leave the tag :)