||IMPORTANT: The content of this page is outdated. If you have checked or updated this page and found the content to be suitable, please remove this notice.|
By default, tasks, files, and other objects in Wikimedia Phabricator are publicly visible (for anonymous users as well), and editable by all registered users. However, sometimes there are reasons to keep some information private. This document explains how private information is handled in https://phabricator.wikimedia.org/.
See also Phabricator/Permissions.
- 1 Requirements
- 2 Preamble
- 3 Understanding 'Security' Field Transforms
- 4 When to Select a Security Option
- 5 Valid Security States for Tasks
- 6 How to Lower the Security of a Task
- 7 Being Open While Providing Private Tasks
- 8 Open / Known Issues Related to Phabricator Security
Tasks regarding sensitive topics need to be filed in Phabricator. Some of these are related to security bugs, and some of these are related to general sensitive work.
Phabricator does not associate policy with any project labels implicitly. Upstream Phabricator developers have affirmed repeatedly that to do so is not in their plan, and it is not intended functionality. The task-centric interface means that policies are explicitly associated with tasks themselves instead. Each task has an "edit" and a "view" policy. The right to adjust policies on tasks is global. In order to grant that right, it has to be granted for all tasks. Because the right to adjust task policy is global it has been limited to members of the Security and acl*operations-team projects.
All users are expected to have the ability to file tasks that require a high degree of discretion, but Wikimedia cannot grant all users the right to adjust policy globally. In order to achieve this, we have created an additional 'Security' drop down field in the task creation form and the task edit interface. This 'Security' drop down allows users to select a transform on a task that appropriately adjusts the viewability/editability without needing global policy permission. This drop down is a transform which sets the appropriate policies, includes relevant projects, and sanitizes the issue if necessary to prevent further disclosure. At this time, the transform is applied as a custom Herald action whenever an issue is saved after editing. To allow for converting existing issues and filing new ones, in a secure state, the transform must be applied any time the drop down is active. The effect of this is that, any time the drop down is active, the basic policy template will be enforced. Changing the 'Security' selector from 'Security or Sensitive Bug' (where it is limited to a known good state for policy) to 'none' does not change the policy on the issue, but it does allow the policy on an issue to be changed. If the determination is made by Security that additional resources are needed after initial filing, this is simple to adjust to allow specific groups or users within Phabricator.
Understanding 'Security' Field Transforms
The latest complete run through of the Security field drop down can be seen in T76564
- Applies no transform
- Preserves the existing policy, project, and other metadata properties of a task.
- MediaWiki security bug
- Ensures the Security project is included
- Ensures the Security project association
- Allow author to edit/view
- Allow any subscriber to edit/view (This is very custom behavior that works only for this setting)
- Allows adhoc additions to policy (users or groups)
- Will prevent accidental "public" or "all users" settings
- Other confidential issue
- Ensures the WMF-NDA project association
- Enforces the WMF-NDA project for edit and view policy.
- Allow author to edit/view
- Access Request
When to Select a Security Option
- None - This is the default under which no adjustments will be made.
- Mediawiki security bug - This is appropriate for any bugs or security issues related to MediaWiki or other Wikimedia software.
- Other confidential issue - This is appropriate for confidential issues within Wikimedia Phabricator, Operations, or any task the author is unsure of for disclosure.
- Access Request - When requesting shell access.
Valid Security States for Tasks
- The default task policies are Viewable by Public and Editable by All Users (registered users)
- Non-registered users cannot manage resources within the Phabricator ecosystem as they do not have an identify to tie audit or actions back to. Public is not a valid edit policy setting in Phabricator.
- Issues that may have policy different from the default: Operations issues that need to be restricted to edit (and possibly view) for WMF-NDA, security issues that need to be restricted to a special group of users, and other issues of a sensitive nature. This list is not complete. There will be instances where a particular task or project is more sensitive for a period of time.
How to Lower the Security of a Task
To make an access restricted task entirely public again, a user who has permissions to modify the task's policy has to edit the task: Set 'Visible to' to 'Public (No Login Required)', set 'Editable by' to 'All Users', set 'Security' to none, and potentially remove projects like 'WMF-NDA' and/or 'Security' if appropriate. Obviously such an action should only be taken for good reasons (e.g. on a security task that has been made public in the meantime).
Being Open While Providing Private Tasks
We want to allow everyone to follow along with project activity. As such, projects meant for ACL use should follow the following scheme separating them:
They should also use the "policy" lock icon.
These are not meant to be applied via type ahead as association projects.
Open / Known Issues Related to Phabricator Security
- Currently the intention for a few specific projects related to Operations is to route certain emails as bot created tasks from anonymous senders.
- The security transform is applied via the existing and known mechanisms outlined above (using the auxiliary field via task creation with Conduit).
- There is no way to set policy on a task via email.
- There is no way to set policy on a task via project association.
- Upstream has declined implicit security behavior with project association.
- In the short term, if a team really needs private tasks for a project, we have to enable this with another option in the Security dropdown.
- In the mid term, we will wait until upstream implements Spaces