On Wed, Jun 22, 2011 at 2:43 PM, Curtis Hovey <cur...@hovey.name> wrote: > 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.
And, given you're talking schemaless changes that implies: bug.private bug.security type-of-bug False False public False True public True False private True True security > 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) I think we need some extra rule that indirect subscriptions are not carried across. > * 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 And here - we need some extra rule that indirect subscriptions are not carried across. > * 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. This would break the contract desired for security bugs: that only the security team can see them. > * 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. +1 > 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. Security need to imply access to private non-security bugs - I think we would have to special case things to have it imply that, so we shouldn't do that. > Launchpad requires that the project maintainer 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. I don't know if this is needed or desirable; large project like Ubuntu may want the project maintainer to delegate and not be involved in day-to-day. Whats the reason for adding this requirement? Is it an implementation strategy or a business rule? The maintainer having access to private bugs makes sense to me as a separate question from maintainer E supervisor. > 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. +1 > 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. I'm not clear how you're proposing to fix this in a schemaless way. Could you expand on that? apport is an interesting case that exploits the current security model for private bugs. However apport shouldn't be filing bugs - it should use a separate crash database and synthesise bugs out from that. As a workaround we can change apport to file its bugs in a dedicated distro|project, and move them to ubuntu when they have had the truely private data elided. (the data that all several hundred Ubuntu devs shouldn't get access to). -Rob _______________________________________________ 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
