launchpad development
Information Types
Launchpad does not have a consistent means to classify the kinds of information that an artefact/page might contain. It is difficult to know who should have access to private data because the reason why the data is private is ambiguous. It is difficult to which rules apply to private data based it is ambiguous.
Contact: Curtis
On Launchpad: disclosure + information-type
Rationale
It is not possible to share all of one kind of information with a user because bugs and branches have defined different kinds of information. Bugs has 4 states two of which are private, branches has two states, 1 of which is private. Information types must be symmetric, or adaptable so that I can share security, user data or Proprietary bug and branch information at the project level. While security and user data can be shared between projects, proprietary information cannot. Information types must be clear to apply rules, explain why something is private, and ensure the proper people have access.
Ubuntu co-opted private to mean user data where it was intended to mean proprietary. Most bugs in Launchpad are private because they contain user data, but Launchpad cannot say that. In a review of private bugs belonging to open projects, most were made private because one comment contains user data.
This issue was discovered while planning Managing Disclosure. Proprietary projects have proprietary data that cannot be shared with other projects. Open projects may have security or user data that can be shared with projects, but are often restricted to a subset of users in project roles.
Stakeholders
- PES
- Steve Magoun
- Cody A.W. Somerville
- Hardware enablement
- Chris Van Hoof
- Linaro
- Kiko
- ISD
- Stuart Metcalfe
Swift <<Commercial example>>
- Monty Taylor
- Ubuntu
- Kate Stewart
User stories
$STORY_NAME
As a project maintainer
I want to state a bug contains user data
so that a bot can be the only thing that can access it.
As a project maintainer
I want to state a bug contains embargoed security data
so that it is clear that only the security team address it.
As a the maintainer of a proprietary project
I want to state a bug contains proprietary data
so that it cannot affect other projects and I decide who it is shared with.
As a project developer
I want to state a branch is a security fix
so that it is only shared with users in the embargoed security policy.
As a driver or an open project
I want state a bug is proprietary
so that I do not need to later state the bug is not a security issue.
Constraints and Requirements
Must
- A user be permitted to state the kinds of data a bug or branch is when it is created. This applies to UI, API, and mail. A user can state a bug is proprietary or user data when it is reported, not just security.
- A user can re-classify the type of information in bug or branch. eg. A bug supervisor must be permitted to state a bug contains user data while triaging. A user can state a branch is proprietary, embargoed security, or user data after reviewing the branch.
- A user must see a definition of the information type so that proper choice is clear. A user might not understand the terms, but he or she must know who will be able to see the bug or branch.
Nice to have
- A project maintainer or commenter can state a bug, branch, or question comment is proprietary, embargoed security, or user data
Must not
- Break email command compatibility: Email commands must continue to work. Users should be informed that the rules have changed, and explain how the private or security command is being interpreted
- Break API compatibility: API scripts must continue to work. Users should be informed that the rules have changed, and explain how the private or security command is being interpreted
Out of scope
- Provide a means to redact the first bug comment and bug history so that a single comment does not force a bug to be classified as user data. This means that large projects can have hundreds of users with access to one or more private bugs because of one made by a user.
Subfeatures
- A choice picker that shows the enum description with the title.
- Replace the bug security and privacy checks with an enum check.
- Add support for many kinds of information to branches.
Success
How will we know when we are done?
- A user can report a bug and state it is proprietary or user data without conflating it with security
- A user make a branch private without the assistance of a Launchpad Admin, and he or she can state that the bug is proprietary embargoed security, or user data.
- A user can be certain that a bug is visible only to a project's security contacts even though he or she does not fully understand what embargoed security means.
- Any user can hide their own comment and a project contributor can hide someone else's.
- When Aport reports a bug, it is classified as user data and only apport has access to it.
How will we measure how well we have done?
- We can query the database to get a list of every private bug or branch and know if it is proprietary, embargoed security, or user data.
- The database can identify proprietary bugs and ensure that they effect only one project.
- A permissions check of all Ubuntu user data bugs in Launchpad shows that Apport and the bug reporter are the only users that can access each bug.
