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

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.

In T131766#2178153, @Krenair wrote:

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.

In T131766#2178296, @MarcoAurelio wrote:

In T131766#2178153, @Krenair wrote:

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.

In T131766#2178296, @MarcoAurelio wrote:

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.

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.

In T131766#2342987, @Luke081515 wrote:

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.

In T131766#2537326, @Danny_B wrote:

In T131766#2342987, @Luke081515 wrote:

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.

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.)

In T131766#2779872, @Aklapper wrote:

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.

In T131766#2779872, @Aklapper wrote:

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.

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*

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

In T131766#2780073, @MarcoAurelio wrote:

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 T131766#2780145, @Aklapper wrote:

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.

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...

In T131766#2780326, @Aklapper wrote:

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.

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.

In T131766#2780488, @mmodell wrote:

@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 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.

@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: acl*stewards created

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

Okay! :)