launchpad-dev team mailing list archive

[Kees Cook <kees@xxxxxxxxxxxxx>]

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