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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
