The Teal Squad is working on the disclosure feature. Our goal is to make
it clear who can know what about a project. One aspect that we concluded
early in our discussions that Lp must stop conflating security with
privacy. This issue seems simple in my head, but I understand this
worries some people. For those that care, please provide your analysis.
By public, I mean visible to every user.
By private, I mean personal or proprietary information.
By security, I mean a vulnerability or exploit.
We discussed a related issue recently about how a bug supervisor is
subscribed when a bug is made private. There are several bugs about this
and they have counter parts relating to the security contact role. I
propose this normalised set of rules that do not require schema changes:
* When a bug is made public => private, the bug supervisor or
maintainer is subscribed. (This rule is closer to what Lp
currently claims happens)
* When a bug is made private => public, the bug supervisor is
unsubscribed (the maintainer would remain)
* When a bug is made public => security, the security contact or
maintainer is subscribed
* When a bug is made security => public, the security contact is
unsubscribed (the maintainer would remain)
* Launchpad's Web UI will continue to enforce the rule that a
anyone can mark a bug as a security issue, and the bug will also
be made private. This is conflated in the UI to encourage open
projects.
* API and Email UI will permit bugs to be marked as private or
security when bugs are created or modified.
* A bug that is private and security will have both the bug
supervisor and security contact subscribed.
* Bug email recipients will be calculated at the time of sending
instead of the moment of creation or modification so that users
can quickly correct a bug's private or security flag and know
that the right people were notified.
Subscription conveys visibility. They are an implicit means of access
control. There will be another means of conveying visibility.
The "managing disclosure" feature of the "disclosure" feature will
permit project/distro maintainers to see all subordinate public and
private artefacts. By assigning a person or team to the roles or
maintainer, driver, bug supervisor, or security contact, you will be
granting knowledge/access to the projects private artefacts. This does
not convey access to security artefacts like bugs (and branches). The
person or team in the security role will have access to public, private,
and security artefacts.
Launchpad requires that the project maintain be a member of bug
supervisor team. The maintainer will always have access to private bugs.
This is not currently true for all bugs because of defects that will be
fixed.
The project/distro maintain may delegate the security contact role to
any team. The maintainer may choose to not have access security bugs and
branches. Subscription will not be a perquisite to to access anything
related to security: eg bugs, branches, archives. We are not creating
more subscription mechanisms for maintainers to manage. The users in the
security role will be able to see the artefacts, though the project
maintain may not if the role was delegated.
The maintainer will always have the power to change who is in the role
of bug supervisor and security contact to change who has access to
private and security bugs and branches. This is not actually doable at
this time do to defects in the security model, but we will fix this
issue.
--
__C U R T I S C. H O V E Y___________
No matter where you go...there you are.
_______________________________________________
Mailing list: https://launchpad.net/~launchpad-dev
Post to : launchpad-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~launchpad-dev
More help : https://help.launchpad.net/ListHelp
