chasemp added a comment. I think this issue is very confused, and confusing I guess, because lots of what is being described is partially true. My thoughts on this especially have become clearer in the last week or so. I will try to write a better explanation when I have a moment but I think a few ideas are particularly poignant.
* Every ticket has it's own security policy (edit / view) * We created an extension that allows the appropriate settings for default security tickets at the time of filing. * These edit / view settings can be changed by anyone with initial Edit permissions if they choose by taking off the option for enforcing security, or we could just make that not continually apply them as is, there were requests for mitigating the problem of 'accidental reveal'. The approach was to make the settings always enforced. * Any group or user can be added to the edit and/or view security settings for a ticket by someone with Policy Edit permissions. That means you can add a group that is all of UI or Analytics or whoever, or all of WMF or all users (if the groupings exist in phab). They can then do whatever they need to do. * There is no situation where we cannot allow all CC users to do whatever the Security group wants them to be able to do per ticket. * But if you add a CC user who cannot edit an issue who wants to add another CC user who is not allowed via the View policy, I think that's where we enter territory we are talking about? I'm not sure what to say other than, policy ACL's are a thing and we'll have to get used to them, maybe find a way to be more liberal with initial permissions based on the type of security issue filed or something. * We can change the default settings for when something is filed as a security bug to be more than the security group initially, or less or whatever we want. * Assignee is the special case for tickets, if you assign an issue to a user they can view it _outside of the view security permission_. They can also edit the ticket _outside of the Edit permission_…for the group of metadata they can already edit globally. Upstreams idea (as far as I understand it) is that assignee is the ticket owner, and don't assign something to someone if you don't want them to be able to manage the ticket. Including adding CC’s (who are already allowed via the view policy), etc. That does not mean they are seen in the view security policy, and does not mean they seen in the edit security policy * Assignee is a bit confusing as far as policy interaction, not the least of which is that Assignee can ‘edit’ the ticket, but the permissions are global for saying who can adjust the policy settings. This should hopefully become much less cumbersome with [[ https://secure.phabricator.com/T3820 | T3820 ]], which is a response by upstream to some of these ideas. The fact that editing security on any ticket at all is one finite global group should hopefully be resolved. * Since we have to assign who can edit policies globally, for now, we are forced to limit it to people who can edit tickets in all contexts for safety, that includes imported RT and Operations use cases. * View privilege users can comment / subscribe / award token / flag / create subtasks * Authors _can_ be excluded from a ticket they created via policy. There was some contention on how that actually worked in the past. Authors are definitely subject to policy. Mukunda and I noodled on it and he came up with an addition to the existing extension that creates a custom policy out of the box for tickets filed as Security Bugs that allows the Author via policy. We can do this kind of thing as it makes sense since policy ACLs are flexible. It partially comes down to what our definition of 'public' is, we can make numerous groups able to best triage / edit / manage 'Security Bug' tickets if that's desirable. Bugzilla has no real concept of access control in the same terms as phabricator, that means the conversation is not apples vs. apples. There is ticket metadata and and there is policy in phabricator. I think we will benefit most by taking what we can do now and seeing how cumbersome it is from a Securities perspective, and then try to get things that will make our life easier included in the https://secure.phabricator.com/T3820 re-architecture. TASK DETAIL https://phabricator.wikimedia.org/T518 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>. To: Qgil, chasemp Cc: wikibugs-l, Qgil, mmodell, chasemp, Aklapper, Dzahn, csteipp, greg _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
