Page MenuHomePhabricator

The case of the Security project
Closed, DuplicatePublic

Description

Let's define the case of the Security project mentioned at T390 and T3820. The strong case for this feature are open source projects, who don't have the luxury of operating in an intranet accessed by users covered by NDAs. Because open source projects are really open, they really need private areas to handle sensitive information.

The following use cases are extracted from Wikimedia's Bugzilla workflow for security issues. I'm calling the project and team "Security", but the same would be applied to other areas like i.e. procurement.

  • A Security product only visible to the Security team (supported in Phabricator)
  • A task created for the Security project could not bypass the project policies, e.g. nobody can create accidentally a task for the Security project that is "Visible to all".
  • When a task reported elsewhere is moved to the Security project, the reporter and anyone CCed still can see this specific task without joining the Security team, they can post comments, and they will keep receiving the related notifications.
    • In Bugzilla you can only choose one product for a task, maybe in Phabricator we wouldn't talk about "moving" but about "adding" and "removing" the Security project to a task.
  • When a task is solved, it is moved out from the Security project to wherever appropriate, becoming visible to all users.
  • "A handful of times each year, someone reports private data as part of a security bug (IP addresses, etc). We need to be able to make those specific comments invisible, or be able to delete them", our Security expert says. The data should not be visible in some diff either. Since these are rare situations, if developing a UI for this would be expensive, a hackish-backend solution would be fine.

Related use cases that would allow us to solve more problems:

  • Members of the Security team can add manually other users in CC, to give them access to a specific task in the Security project, allowing them to receive notifications as well (supported, I guess).
  • Registered and non-registered users can report tasks for the Security project via email.
  • Registered and non-registered users can comment to tasks for the Security project via email, after receiving the email address from the Security team.

Related Objects

StatusAssignedTask
DuplicateNone
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedchad
Resolvedchad
OpenNone
OpenNone
DuplicateNone
Resolvedchad
ResolvedNone
Resolvedhsb
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedjoshuaspence
Resolvedepriestley
Resolvedbtrahan
Resolvedbtrahan
Duplicateepriestley
Resolvedepriestley
Wontfixepriestley
Resolvedepriestley
Resolvedepriestley
DuplicateNone
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
DuplicateNone
DuplicateNone

Event Timeline

qgil raised the priority of this task from to Normal.
qgil updated the task description. (Show Details)
qgil added a project: Policy.
qgil added subscribers: epriestley, chad, btrahan and 8 others.
qgil edited this Maniphest Task.
qgil raised the priority of this task from Normal to Needs Triage.Apr 24 2014, 5:34 AM

I think this mostly maps to T3820, as per T4893#12

The email stuff is a bit special, but easy in a world where T3820 exists and works properly.

"A handful of times each year, someone reports private data as part of a security bug (IP addresses, etc). We need to be able to make those specific comments invisible, or be able to delete them", our Security expert says. The data should not be visible in some diff either. Since these are rare situations, if developing a UI for this would be expensive, a hackish-backend solution would be fine.

I think the stuff in T4909 covers this now.

Ok, I will merge this to T3820 in order to keep the discussion in one place.

✘ Merged into T3820.

epriestley closed subtask Restricted Maniphest Task as Wontfix.Aug 6 2014, 9:00 PM