launchpad-dev team mailing list archive

[Edwin Grubbs <edwin.grubbs@xxxxxxxxxxxxx>]

On Tue, Sep 21, 2010 at 10:58 AM, Curtis Hovey
<curtis.hovey@xxxxxxxxxxxxx> wrote:
> A Brief Primer on Launchpad Privacy (issue 4)
> =============================================
>
> Private Primary Contexts
> ------------------------
>
> A private project, distro, project group, team, meeting or possibly user may
> have any Launchpad ID. The "private" name prefix used by private teams was
> rejected by team owners; no person was concerned about other users guessing
> their names through deduction during the registration process. We can consider
> requiring a private prefix if Canonical and its partners request it.
>
>
> Projects and Distributions and Teams
> ....................................
>
> For projects and distributions, the private primary structure rule means
> that series, milestones, releases, downloads, and announcements are private.
> They cannot be made public and users cannot be subscribed to these items
> to gain access.
>
> For teams, archives, mailing-lists, and polls are private. This is true now.
> When teams are used in project or team roles (owner, driver, members, mirror
> admins), the team must be restricted to ensure a user cannot gain access
> though team membership.
>
> The TeamParticipation code requires review and probable revision because
> this mechanism for determining indirect membership is not aware of privacy.
>
>
> Project Groups
> ..............
>
> Project groups can be private, and so too will their reports about
> series and milestones. Teams in project group roles must be restricted.
> Private project groups can have public projects, and public project groups
> can have private projects. Projects do not inherit permissions from their
> project groups because they are not subordinate; they have an independent
> URL.
>
> Project Groups are problematic and several issues must be fixed before privacy
> can be added. Project Groups provide a means to add a team of drivers
> to all the grouped projects, and get reports about the series and milestones
> that belong to those projects. There are no guards in Launchpad to ensure
> the owner of the project group is also the owner of the grouped project. This
> problem is an annoyance now, but it will become a security risk if not solved.
>
> This problem exists because Project Groups can also be used for affiliation--
> my project uses GNOME so I make my project a part of your GNOME project group.
> The affiliation behaviour is flawed because my project could also be related
> to Python and Ubuntu. If Launchpad must support project affiliation, a new
> mechanism is needed.
>
> There have been suggestions to abandon project groups in favour of nested
> projects, just like teams. This introduces a similar solution and problem
> as TeamParticipation. The rule of ownership stated above must still be
> implemented. This solution does not directly solve the control problem,
> but it does allow the parent project (group) to have bugs, questions, branches
> translations which alleviates some awkward situations when items do not
> really belong to a specific project.


The loose connection between project groups and projects is another
situation that works fine for open source projects with community
ownership but is not what a company is going to want for a projects
they control.

Auditing access to all aspects of a single project will work fine for
organizations with just one project, but it will break down when they
add more. We could give Project Groups two very different behaviors
depending on whether it is meant to hold public or private projects,
or we could think of the organization as the object that controls the
privacy of all other objects belonging to it and can audit them. An
organization could just be another team with added features enabled.

-Edwin

> User and Meetings
> .................
>
> Users and meetings qualify to support privacy because of the primary context
> rule. We do not have any use cases for a private person, so there is no
> immediate plans to implement privacy for users. There have been requests
> to support private meetings (sprints). We do not have immediate plans
> to add privacy, but it can be considered.
>
> --
> __Curtis C. Hovey_________