launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Wed, Jun 22, 2011 at 2:43 PM, Curtis Hovey <curtis@xxxxxxxxxx> 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