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: #operations , author, assigned, CCed.
This is how it would look like in the task creation page:
> Security None
> MediaWiki security bug
> Other confidential issue
-------------
NOTE:
* 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 2 of https://gerrit.wikimedia.org/r/#/c/183457/:
Security-Bug:
[x] Creating an issue with security-bug allows the author via policy
[x] Creating an issue with security-bug allows members of Security via policy
[x] Modify policy with security-bug enabled to allow a specific user via policy
[x] Modify policy with security-bug enabled to allow a specific group of users via policy
[x] Creating an issue with security-bug associates Security project
[x] Creating an issue with security-bug allows non-Security project
[x] Security-bug does not allow an issue to be set to view for public while enabled (yes but with big caveats for herald)
[x] Security-bug does not allow an issue to set to all users for edit (yes but with caveats)
[x] 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)
(This seems not to be working as I created T499 on phab-01 and added a user to only CC (no other relation and they could not access the issue. The rule appears to be present, but isn't working?)
[] Setting an existing issue 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)
**[] Prevents users from CCing themselves via Herald [1]**
Sensitive:
[x] Creating an issue via Sensitive allows the author via policy
[x] Creating an issue via Sensitive allows members of the WMF-NDA group via policy
[x] Creating an issue via Sensitive associates the WMF-NDA project
[x] Sensitive does not allow an issue to be set to view for public while enabled (yes but with big herald caveats)
[x] Sensitive does not allow an issue to set to all users for edit (yes but with big herald caveats)
[x] 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.
**[] 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?)[1]
**
Default:
[x] performs no transform on new issue
[x] performs no transform on issue set to none from other
1 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?)