launchpad-dev team mailing list archive

[curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

This is a long email summarising the proposed changes the Teal Squad
will make to privacy and security rules in Launchpad. Policies will be
introduced to control who has access to certain kinds of project
artefacts. Bug and branch rules will be reimplemented using policies.

You do not need to read this now, but you should save it so that you can
refer to these changes when they appear in a few weeks.

One Policy to Rule Them All

Teal Squad members and Robert discussed how to resolve issues about
who gets access to projects artefacts and how to report who has that
access.

We will create a single mechanism the defines visibility policies for
projects. All projects will have a sane default set of policies enabled
when Lp Bugs or Lp Code is enabled. Maintainers can add users and teams
to policies. The polices control access all project items that they
pertain too; they are not bug, branch, thing specific.

We must build a mechanism to support the project observer use case. This
mechanism will be simpler to report, faster to query, and easier to
extend then the flawed/contradictory polices embedded in the Lp Bugs
code. Extending the proposed mechanism to Lp Bugs means we want to
support the security policy used by many projects and the apport policy
that Ubuntu created by taking advantage of defects in the existing Lp
Bug policy code. This simplified policy mechanism will also be used for
branches; the complex multi-tenancy rules will be replaced. Branches
will gain security policies as a consequence.

We do not want to reinvent a new UI to manage the creation/deletion of
polices. It would be nice to know we could keep the existing UI for
showing who has access to private/security bugs/branches, but I think we
need to evaluate the cost of implementing one UI verses what is shown
or not shown on bug and branch pages. That is to say. Lp has never told
the truth about who has access to private or security bugs, and branches
go out of there way to not say anything informative. We will either fix
bugs in an ad hoc fashion or commit to common presentation that we can
use when we need to inform the user.

The project bug and code pages should show or provide a link for me to
know who will see my private bug/branch. When I say a private bug
affects another project, I need to be told who I am revealing this
information too. There will be cases where private teams will be
involved. Since the team is in a public position, I will know its
Launchpad-Id and display name. If I do not trust that little information
I can choose to not report the bug. I expect to see a message like: Bug
reports are initially private and are visible the foo-maintainers and
bar-employees.

There are some subtle changes that need to be communicated in the UI.
Bug supervisor and Security contact information that appears on the
project bug page would be ambiguous if left on changed. The security
contact role is unneeded unless we want to modify it to have bug editing
permissions. Bug supervisors do have bug editing permission, and that is
all that the role will convey. Access is governed by policy, and
notification is governed by subscription.

Bugs will continue to have the portlet listing security and privacy. The
mechanism that says a bug pertains to a policy may change, but the UI
does not need to. The same is true for branches.

We are not building a UI to define new kinds of policies. It is not a
requirement for disclosure. It is also fraught with problems. We defined
the meaning of private and security_related. We understand the meaning
of apport. When public projects share private bugs, their policies must
be in agreement. That is to say, two projects could define a kind of
policy called oem-engineering and mean different things, and
confidential information in the bug will be leaked. This is a vector for
social attacks.

There will be default policies for new projects:
    Maintainer has access to all security related project items.
    Maintainer has access to all privacy related project items.
The default maintainer is a user or ~registry. We want to require
teams that maintain projects to be restricted or moderated.
Open/Delegated teams cannot be project maintainers, nor can teams become
Open/Delegated if they are are in a policy. Teams that act as security
contacts will also be required to be restricted or moderated since there
purpose to to deal with vulnerabilities.

Teams in the driver or bug supervisor roles can be open. This means
though that they cannot access private or security bugs and branches.
This is a change in the documented Lp Bug policies, but is not a change
to the code that supposedly enforced those policies for many years.
Maintainers delegate the management of releases to drivers, and the
triaging of bugs to bug supervisors. While the permission for these
roles are still broken in Lp, the ability of drivers to edit series,
milestones, and releases, and bug supervisors to edit bugs is very
important. Small projects do trust users to join teams and make
contribution without the help of team admins.

Maintainers can add a private observer by adding the user or team to the
privacy policy. We expect all Canonical owned projects have ~canonical
in their privacy policy. Other organisations will do something similar
for their teams. Some projects may choose to have more than one team in
their security policy.

Maintainers can still subscribe users or team to some bugs and branches
to give them access to a few issues in the project. This restricted
observer role will be able to traverse to private bugs and branch pages,
and they are permitted to know anything shown about the project on those
pages. The act of subscribing is always about sending notifications to a
user. When a user is subscribed to a private bug or branch, the user is
also being given restricted access. It must be clear to the person who
does the subscribe action that permission will be given where there was
no permission before. We /could/ build a mechanism that grants access to
bugs without subscribing users *but* the main need to subscribe someone
to a private bug or branch is so that user can contribute; the user
needs access and notification.

Lp will not permit anyone to subscribe a open or delegated team to a
private bug or branch because only restricted and moderated teams can be
in a policy. Teams will not be permitted to become open or delegated if
they are in a policy or subscribed to a private item. There will be
checks to prevent team merges that will compromise projects.

Maintainers can remove teams and users from policies, which removes user
access to private or security items. Maintainers can also remove teams
from policies *and* unsubscribe the team and its members from bugs and
branches to remove all access to the project. This will not be a real
time operation since thousand of bugs and branches will need examination
-- users can legitimately retain bug and branch subscriptions because
they are in teams that are in a policy.

When a bug or branch is made private or security_related, the bug
subscribers will be changed. User and teams without a policy will be
removed. Though Lp may have code in the send mail rules to ensure
subscribers not in the policy do not get mail, it is *scary* to see
subscribers listed who will not see the notifications. The subscribers
list must be accurate to gain the confidence of users working with. It
must also be clear that making a bug or branch private or secure will
unsubscribe users not in the respective policy.

In cases where projects share bugs, they must have comparable policies
for the bug's state. Ubuntu will have an apport policy and we are not
planing to create a policy for other projects. Thus apport bugs will
only affect Ubuntu, the bug can be made non-apport so that it can affect
another project. It is hypothetically possible for a project to remove
all users and teams from a policy, and in such as case with bugs, no one
in one of the affected projects will see it. Lp must make this situation
clear.

I want to stop the direct subscription of users and teams to bugs
because they are private or security related. Teams/users setup
structural subscriptions to get the notifications they care about.
Direct subscriptions can cause users to get unwanted email. Maintainers
have less to audit if there are fewer direct bug and branch
subscriptions. We want to ensure users can setup subscriptions to
private and security bugs. Maybe we want to offer default subscriptions
for teams in certain roles. We also want to ensure users do not get
notifications if they are not in the correct policy.


-- 
Curtis Hovey
http://launchpad.net/~sinzui

Attachment: signature.asc
Description: OpenPGP digital signature