launchpad-dev team mailing list archive

[curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

Hi Francis, Matthew, rocket scientists.

I am reopening this thread about know who may know who has access to a
private bug. There may be conflicts of *trust* with some existing
workflows. We may only have a problem with Ubuntu because it is the only
project that chooses to silo security contacts, maintainers, and drivers.

When a project shares a kind of information, the users and teams get
access without notification to private information. Only the maintainer
can share a project. Drivers can see who these users and teams are.
These users and teams are *not in a public relationship*. By that, I
mean Lp is not obligated to reveal their names. Teams can choose to
reveal themselves by subscribing to get bug notifications.

1. When project maintainer or driver reports a private bug, the privacy
portlet could show a link to the sharing page. If I am curious about
with whom the project has chosen to share the bug's information, I can
follow the link.

2. When a normal user reports a bug on a project with default private
bugs, does that user get to know the name of all the teams and user the
project shares with? I say *no* because this is the inverse of
private-team-spying case. Private teams cannot spy on public bugs (they
must reveal there name); users cannot create private bugs to spy on the
private teams (trick Lp into revealing names). A team admin must agree
to reveal his teams name. As the team admin has not agreed in this case,
the name cannot be revealed. Users must trust that the project
maintainers are being responsible when they sharing private information.

3. Argument 2 also applies to projects with public bugs that can become
private. If a bug becomes private, the reporter does not get to learn
additional information.

NOW THE PROBLEM

4.a. When a member of the security contact reports or reviews a bug, he
or she reviews who the information is disclosed to. The member cannot do
this if he or she is not also a maintainer or driver. Should the
security contact trust that the project is setup properly? We reviewed
this case in the database a few months ago. While maintainers or drivers
can be divorced from security contacts, this only happens in
Ubuntu...the Ubuntu maintainers have chosen not work with Embargoed
Security or User Data bugs. This rule will continue with sharing.

4.b. Since there is no overlap between the roles and what is shared, the
people who work with security bugs cannot audit who has access. The
people who can audit cannot see the bugs that someone wants to audit.

4.c. This project setup appears to be vulnerable. As the maintainer of
several projects for an organisation, I could share everything with
myself before I leave the organisation in hopes that no one will unshare
with me. Maybe I get access to someone's computer and share the
project's with myself. I then use my browser or API to look for new bugs.

POSSIBLE RESOLUTIONS

1. Maybe there is nothing wrong with the UI for security users, the
maintainers have shot themselves in the left foot. Send an email to
maintainer when sharing changes to ensure they are informed. Security
contacts do not need to be informed.

2. Maybe Lp should not permit this? The security team in this scenario
is working independent of maintainers and drivers? They cannot use Lp to
coordinate activities because they are siloed. This is hard to enforce
because team memberships change over time. For example, to get around
the maintainer-must-be-a-bug-supervisor rule, I leave the team after I
set it in the bug supervisor role.

3. Maybe the users a project shares with may know each other? If I can
see all Embargoes Security information, then I may know who else the
project has shared the information with. When someone comments on a bug
that is not subscribed, I have learned something that Lp is keeping
secret. This might happen often. We do not official care about this
case. Lp could show a list of the users and teams that are in a sharing
policy to users who are in the same policy. If I am in the three sharing
policies, I can see with whom the project shares All, but not Some.

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

Attachment: signature.asc
Description: OpenPGP digital signature