launchpad-dev team mailing list archive

[Curtis Hovey <curtis@xxxxxxxxxx>]

On Wed, 2011-06-22 at 15:27 +1200, Robert Collins wrote:
> 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

^ security is true, the bug is security.

> True             False              private
> True             True               security

Per a follow up conversation, this is correct security prevails over
private.

> > 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.

We do not need a rule, we need to remove the idiotic rule that is in
place now. When bug is made private/security, bug subscriptions are
created from structural subscriptions. This is rule is confusing because
we often say we converted an indirect subscription to a direct one. that
has never been the case. You can see the truth of this in the UI,
structural subscriptions are never listed on private/security bugs.

We will delete the rule, code will be faster.

> >      * 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.

As above.

> >      * 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.

I agree it does and I rescind this rule. the correct rule is that
security prevails, it is private, but the the bug supervisor does not
have access even though th bug is private.

The rules must ensure private+security = security, and the bug
supervisor and security contact subscription rules needs to account for
this. This is not an issue for the role-based rules, where it is clear
that security is only visible to security.

> >      * 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.

Well, since the security team is in the security contact role, the user
do have access to everything in the project :) I do not think it is a
special case.

Subscribing a user to a private or security bug will allow the user to
access it and get notification. If this user is not in a project role
for a private project/distro, he will have partial access to the project
so that he can traverse to his subscriptions. he can know the names of
the artefacts, but not know their content.

Note that in the future, project owner will be able to granted
permission to see the whole project, but not be in a role that convey
extra permission or responsibility.

> > 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.

I do not know the background for this rule bug supervisor role. I know
that no user has reported a bug about this, though to lp engineers have
after reading the code. I am not inclined to increase scope unless I
must.

> > 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?

Any maintainer can change these roles now, but launchpad does not
reconcile the role change with the bug subscriptions. Launchpad could do
this now, it just choses to let the maintainer bang his head against the
wall when he learns that two separate groups of users now have access to
the bugs.

In a related change, "managing disclosure" permission changes, we will
shortcircuit subscriptions for project level permission. This certainly
requires a schema change.

> 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.

Indeed I was thinking that this is a case where th bug is not finalised.
The bug is in a intermediate state between reporting and created. Maybe
be this is a state before NEW.

This is an interesting issue. I am sure we can accommodate apport with
struggle.

> 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).

mayeb

-- 

__C U R T I S  C.  H O V E Y___________
No matter where you go...there you are.