On Tue, Jun 21, 2011 at 22:43:38PM -0400, Curtis Hovey 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. > > 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.
Are you considering this a tristate? public/private/security, or are you considering it as 2 booleans? public/private and security/non-security? I ask because I see the "security => public" transition mention above, and that doesn't make sense to me. :) Most security issues are public. Some aren't. Security issues must start their life as private so that there is no initial leak if a reporter wishes it to be private. -Kees -- Kees Cook Ubuntu Security Team _______________________________________________ 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
