Revisions and Commits
| Unknown Object (Diffusion Commit) | |||
| rPHES phabricator-Security | |||
| rPHES0a8456b10481 Don't strip projects from newly created tasks | |||
Related Objects
- Mentioned Here
- T475: Authors of private tasks should be able to access them
Event Timeline
Are we migrating private tickets in this bugzillapreview? Even if we do, since they are private tasks and the purpose of this preview is public scrutiny, I would be ok if we announce bugzillapreview with this known issue still open.
@chasemp: If we merge the patch from T475 ( https://gerrit.wikimedia.org/r/#/c/163753/ ) then this task doesn't make as much sense.
The patch for T475 sets the policy to "members of projects the task is part of" and the security plugin needs to ensure that a task isn't added to an insecure project thus revealing it to people who shouldn't be able to access the secure task.
In general I think it only makes sense to have "tag" type projects in addition to the secure "group" project.
...anyway it's not entirely straightforward and I'm still not sure what's best.
So it totally makes sense I think. The tags themselves in no way are associated w/ the security settings. Adding a project doesn't affect the view/edit policy settings at all. Right now when we create a new security-bug we are stripping out all tags but security (which is a group), but if am in #MYGROUP and #MYGROUP is added to a security task (that is hidden from me) as a project. I do not automatically get to view that task.
The work for T475 should create a custom ACL that is essentially SECURITY+Author for each newly filed security task. It shouldn't have anything more to do w/ any other projects associated to a task at creation time than that. I don't see this quote "members of projects the task is part of" anywhere but it is wrong and wouldn't have made any sense prior to this T716 as no other projects have been allowed. Maybe best to do a quick call on this?