Show the name of the private team in the public role

[Curtis Hovey]

private team names and displaynames can only be known to team owners and members. If a private team were placed in a public role observers would see <hidden name>, which is in appropriate. When a private team is in a public role, other users need to know not only of the existence but also the name so that it is not possible to spy on projects or users.

The affected roles include: project maintainer, driver, bug supervisor, security contact, and artefact subscribers.

The current implementation raises an authorisation error if the user does not have permission to access the team. This issue implies that some contexts for team access should permit accessing the team name and displayname. This scenario is challenging. Over the API I would get an error doing:
    team = lp.people['~private-team']
    team.name
but not an error when I do
    project.team.name
    a_team = project.team
    a_team.name

Maybe the rule can be simplified? When a team is placed in a public role, a flag on the team is set to indicate that anyone may know the team name and displayname in any context. When the team removes itself from public roles the flag is unset.

[Curtis Hovey (sinzui)]

Robert does not like the use of a flag or enum to identify when a team name may be known because it ignores context. When a team is placed in a position where another party must know the team name, context is established and only the other party should know of the team.

We want a solution that also address the case of traversing a private project. When a private project give me access to a bug targets to a series, I may know the project and series name/displayname because I must traverse them to get to the bug. The bug may show the names. I may also learn the milestone names shown on the bug, as well as the private team assigned to the bug.

An adapter might solve the issue. adapting an object to IRestrictedObserver could do the proper security check and return either the object or a light representation that only provides access to type, name, and displayname. Consider that most code faults when dealing with private teams were working with displaynames and names. In many cases, they will not raise an unauthorised error if the result set returned the correct items. The tales adapter for team could assume the user has access and catch the UnauthorizedError and return <Hidden name>.

Robert also suggest that instead of solving a hypothetical case, a good solution will solve the case where a user is granted access to a private team's archive. The user may know the name and displayname of the team, can may see the PPA page and subordinate pages. The user may not see the other PPAs, or other team pages.

[Robert Collins (lifeless)]

See also bug 405277 which has a fairly comprehensive analysis about this sort of issue.

[Curtis Hovey (sinzui)]

We have solved the traversal case where archive and branch subscribers may know the identifying information about the private team.

We need to solve the cases where the user may know the private team's identifying information, but it is not obvious from the request that the user is permitted. Consider the API scenario where a private team owns a public project. After I retrieve the project, accessing project.owner must succeed. I may access the LimitView attributes like name and display_name.

The purple team is sceptical that a comprehensive and fast query can be written without denormalised data. There is a finite number of public interactions that are currently implement and queries could be written to check those:

    Product.owner
    Product.security_contact
    Product.driver
    Product.bug_supervisor
    Distribution.owner
    Distribution.security_contact
    Distribution.driver
    Distribution.bug_supervisor
    Project.owner
    Project.driver

    BugTask.assignee
    Branch.owner
    Branch.reviewer
    BranchMergeProposal.reviewer
    CodeReviewVote.reviewer
    Specification.approver
    Specification.drafter
    Specification.assignee
    Question.assignee

    BugSubscription.person
    BranchSubsription.person
    SpecificationSubscription.person
    QuestionSubscription.person

^ This check must exclude deactivate projects and products. It must exclude private projects and distributions in the future (which will be tracked in separate bug)
^ Private bugs and branch are not public interactions.
^ CodeReviewVote is tainted. Teams cannot vote, but a team can be placed in a voting position temporarily.
^ Branches owned by a private team on a project not owned by the team reveal the team.

I think someone of these columns could be treated as separate bugs. The case of a private team's branch on someone else's project might not be a case of public to everyone. Maybe the branch is revealed to the users in the project privacy/security policy.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r14588 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/14588>.