Currently the Security dropdown has these options:
- none
- Security or Sensitive Bug
- Private Issue
The scope of each option is unclear, and the implications of filing a task in one bucket or the other are unclear as well. There is no documentation in mw:Phabricator/Help.
Especially now that we are focusing on the RT migration (which might/will bring more options) we should clarify this.
PS: this came up in a chat with @csteipp.
Proposal (work in progress):
- MediaWiki security bug. Report of a security breach in MediaWiki software, extensions, apps, elsewhere... Planned to be public after the bug has been resolved. Can View: Security , author, assigned, CCed.
- Other private issue. Task most likely related to the Wikimedia infrastructure, triaged by the Operations team. Most likely it will remain private. Can View: SRE , author, assigned, CCed.
This is how it would look like in the task creation page:
Security None
Software security bug Other confidential issue
- the key for MediaWiki security bug is security-bug
- the key for Other confidential issue is sensitive
- the key for none is default
I updated phab-01 to intended versions for arc/libphutil/phab/sprint/security.
Based on patch set 3 of https://gerrit.wikimedia.org/r/#/c/183457/:
Security-Bug:
- Creating an issue with security-bug allows the author via policy
- Creating an issue with security-bug allows members of Security via policy
- Modify policy with security-bug enabled to allow a specific user via policy
- Modify policy with security-bug enabled to allow a specific group of users via policy
- Creating an issue with security-bug associates Security project
- Creating an issue with security-bug allows non-Security project
- Security-bug does not allow an issue to be set to view for public or all users while enabled (yes but with big caveats for herald)
- Security-bug does not allow an issue to set to all users for edit (yes but with caveats)
- Setting an existing issue from none to Security-bug performs policy manipulation to make the task secure (this means not allowing public or all users) (this will not strip existing CC's programatically)
- Creating an issue with security-bug allows CC'd users via policy (view and edit)
- Setting an existing issue as Security-Bug associates the Security project
- Prevents users from CCing themselves via Herald [1] (on new creation yes but not if a user tries to public an issue accidentally)
Sensitive:
- Creating an issue via Sensitive allows the author via policy
- Creating an issue via Sensitive allows members of the WMF-NDA group via policy
- Creating an issue via Sensitive associates the WMF-NDA project
- Sensitive does not allow an issue to be set to view for public while enabled (yes but with big herald caveats)
- Sensitive does not allow an issue to set to all users for edit (yes but with big herald caveats)
- Setting an existing issue to Sensitive performs policy manipulation to make the task secure (this means not allowing public or all users and allowing WMF-NDA and author via policy). This is caught by the herald rule so it comes with herald caveats but seems to work from testing so far.
- Setting an existing issue as Sensitive associates the WMF-NDA project
- Prevents users from CCing themselves via Herald [1] (on new creation yes but not if a user tries to public an issue accidentally)
Default:
- performs no transform on new issue
- performs no transform on issue set to none from other
- Prevents users from CCing themselves via Herald on a security issue someone tries to set as public (this is done via a last check herald rule for now that means regular users can CC themselves on a security issue that someone tries to set as public. The public will be rescinded but their CC will remain, and because of intended CC functionality they will have edit/view permissions all from a sneaky herald rule. This is especially strange as setting an issue for view to public allows a user who has an "always cc me herald rule" to sneak in, but setting to edit seems not to. Bug in phab?) This also creates an issue with security-bug issues where if a user has an "always cc me" rule they cannot be removed from CC as the herald processing works before the permissions are removed continually readding them. That mean a user can effectively create a herald action that makes it impossible to remove their access to a security isue as CC == policy perms. Without this we cannot enable herald for all users.