launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

Hi Curtis,

Thanks for this thorough analysis. One thing that I'm not clear on: with
your new rules, are we dropping the support for public security bug? (A
bug marked as a security vulnerability but is not private?)

Or would they just become "public bug" as part of your rules?

Cheers

On 11-06-21 10:43 PM, 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.
> 
> 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.
> 

-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

Attachment: signature.asc
Description: OpenPGP digital signature