- Due Date
- Fri, Feb 1, 9:00 PM
|Open||None||T105404 [EPIC] Gather requirements from teams for Phab project management feature requests|
|Open||None||T92708 Add fields to support bug specific information|
|Open||mmodell||T93499 Add support for task types|
|Open||chasemp||T204160 Create a security issue task type with additional attributes|
. @20after4 and I are talking about doing a few things: Creating a task type 'security' Have due date and risk rating on the advanced form for creation Have a simple form for creation as the one that exist now see if we like this convert existing open tasks we want to use the new task type?
I'm reopening to keep the narrative on this subtype complete. We noticed that users who had edit perms on task were not able to modify the task. @mmodell changed some permission on the view I believe? I'm not sure if this has resolved the issue.
Here is a current use case for example:
- T208008 was created with Form 48
- Task policy says Security, author, or subscribers can view
- Explicit edit policy says all users but implicit here is you have to be able to view it first
- @Anomie is a member of Security and can view the task but in https://phabricator.wikimedia.org/T208008#4724709 and https://phabricator.wikimedia.org/T208008#4725444 reports he cannot edit projects on the task
Yeah, editing the task title and description (and adding a comment) is possible but none of the metadata fields (status, priority, assignee, tags, subscribers) are editable, except the workboard column.
I would have figured the form would have a policy for changing the form itself (fields etc) and then tasks would have a policy for the forms implementation. It sounds like the task can be less permissive than the form (which allows edit for the actual form) but not more?
The policy for who can edit the forms themself is controlled by the application policy. Phabricator's forms and policies are quite confusing, somewhat more so once you add types into the mix. It does work pretty well it's just not exactly intuitive.
Ok thanks @mmodell, I want to run the use cases / workflow by the rest of acl*security_team, and I'm learning about the form/task stuff on the fly so I appreciate your patience. I'll sync up with you sooner than later.
For now I've added Security to https://phabricator.wikimedia.org/transactions/editengine/maniphest.task/view/48/ (option #2)
This should get us over the current hump (I think?) as those tasks are really only visible to Security anyway.
I'm wondering if this isn't just fine tbh after the addition of Security
- Status and assignee are mainly used by the people working on a task, so Security makes sense.
- Priority is mainly used by the team overseeing the area, so Security or even acl*security_team would be fine.
- Tags are IMO more akin to editing the description, anyone can do useful work on those; plus, some people use personal tags to track issues relevant to them. It's also a relatively harmless field (although all the others are too) so I'd make editing it more open. (I guess the biggest concern there is an attacker who somehow gains access removing things from security to make them harder to track, but that doesn't seem like a big risk.)
- Subscribers are the most borderline - non-security-members who are more familiar with the relevant community inviting people knowing more about an issue is a good thing, OTOH it can result (even with good intentions) in the task being visible to too many people / potentially easily accessible to an attacker who can steal wiki accounts. Not sure about that one.
IIRC this was mainly just for the author, relevant developers, and other people who either need to know about the bug (as they need to fix it) or already knew about it anyway. People shouldn't be adding their friends to security tasks just because like what was suggested at T207323. I don't know the extent to which it makes sense to enforce extra controls on who can subscribe people however. Is there at least a warning notice about this?
(response for you both and just to expound a bit generally)
At the moment all of this conversation only relates to tasks created using (or converted to) the subtask type in discussion. We have had an issue with chains of CC users (where one person is added who adds another and so on) for which we don't have a reason or idea of why they are currently CC'd on a task. This is further compounded by our desire to keep (as much as possible) security tasks limited to those with 2fa on their accounts in phab.
This is part of what I'm thinking about here definitely. Recently this caused confusion and worry with a few tasks where they were being overloaded across specific issues (one problem) and that meant the spread on users who could access was a bit out of control (separate problem for sure). 43 CC'd users in a case where it became very problematic to contain our immediate responses to issues. Quite a few no one I talked to knew why many/most of those were CC'd and even in a few cases the CC'd users themselves had no idea :)
The new subtype is being piloted for a few reasons that all boil down to needing more and different fields and subtypes being the native mechanism to make that happen. In parallel it potentially provides us with some new and better elements of defining appropriate access to security tasks. But part of the pilot (so to speak) is figuring out how forms and views are best utilized here. Before anything goes much further than the handful of tasks at play now it is my intention define expectations better, esp for things that are changing.