launchpad-dev team mailing list archive

[William Grant <william.grant@xxxxxxxxxxxxx>]

Purple Squad's unified sharing model lets projects manage who can see
private bugs and branches. It replaces the bug and branch
subscription-based access control lists, and it replaces most of
BranchVisibilityPolicy's functionality.

But one bit of BVP remains unreplaced: defining who can *create* private
branches. We also don't have a really good answer for the same question
for bugs, even now.


Original behaviour
------------------

Before Better Privacy, bugs and branches had divergent access control
mechanisms.

New bugs were public by default, unless the project had the private_bugs
flag set, in which case they were private by default. In either case,
users could select a checkbox to make their new bug private+security
rather than private or public. After filing, anyone who could see the
bug was able to change the private and security flags to any value.
There was also an undocumented feature used by Ubuntu's apport to file
private non-security bugs in Ubuntu, as if it had private_bugs set.

The rules around branches were a little more obscure. New branches were
public, unless the project had BranchVisibilityPolicies configured. A
BVP overrode the public default, causing branches for members of a
certain team to be public, private, or disallowed entirely. There was no
way to override the default when creating a branch, and in normal
circumstances only a Launchpad admin could change the privacy after
creation.


Use cases
---------

Different projects use bug and branch privacy in several different ways.

Ubuntu primarily uses public bugs and branches; both should be public by
default. But Ubuntu also makes extensive use of private user data and
private security bugs. User data bugs tend to only be filed by apport,
but it's not clear that they're not desirable in other cases too.
Private security bugs are filed by users and the security team to track
embargoed security issues, through an option on +filebug. Both user data
and security bugs are frequently disclosed later when they no longer
contain confidential information. It's also reasonably plausible that
they might want to use private security branches in future.

Ubuntu One Servers has private (proprietary) bugs and branches by
default. Its branches are exclusively proprietary and can only be
created by its engineers, but it extensively uses public bugs, with a
smattering of private security. All bugs start private, and anyone can
file one, but a combination of reporters and engineers make them public
as appropriate.

Launchpad, like most FOSS projects, nowadays mostly uses public bugs and
branches, except for the very occasional private user data or security
bug. Both should default to public, but we need the ability to create
private security bugs and branches as required.

Launchpad in 2008 mostly used public bugs, but only proprietary
branches. Bugs defaulted to public, but engineers occasionally filed
private bugs containing code details. Like other proprietary projects,
only engineers could create branches.

Hypothetical Proprietary Project uses only proprietary bugs and
branches. Everything starts private, and cannot be made public. Only
engineers can create branches. Depending on how they feel, they might
let anyone file a bug, or in the future they could be a private project
that restricts bug filing.


The future
----------

BranchVisibilityPolicy and probably Product.private_bugs need to be
replaced in ways that are compatible with the example projects I
outlined above, and probably more that I have not considered.

They need to both support customising the default. They also need to be
able to restrict certain types to certain groups of people (a normal
user can't create a public Ubuntu One Servers bug, and nobody can create
a proprietary Ubuntu bug or a public Hypothetical Proprietary Project
bug), both during and after creation. I don't know how best to model this.

Ideas? Cases that I haven't considered? Anything?

William.

Attachment: signature.asc
Description: OpenPGP digital signature