Search for reviewers should be limited to lookup team-members, and not be a wildcard search

Noon Silk avatarNoon Silk created an issue

It is a security flaw to allow users to be listed on the site; which is what this does. The workflow is also weird if you're trying to send pull requests to team-members only, and it keeps showing you unrelated people. It should be possible to filter it to team members for the searching, and just flat-out not return searches for users not in a team.

Comments (16)

  1. Erik van Zijst

    User accounts on Bitbucket are not meant to be invisible and so I do not see how them showing up in autocomplete is a security issue.

    As for the autocomplete including non-team members, this is also by design. Not everyone you want to review a PR might be a team member. They might have direct access to a repo, or the repo might be public.

    What we do do however, is prioritize team members over other users when sorting. We also label them with the TEAMMATE lozenge.

  2. Noon Silk

    Re security issue - It's wildly considered that having a list of users is a security flaw in that it provides a source of valid usernames which can have some value if someone wants access to just any valid account, instead of a specific account, which is a standard technique.

    For auto-complete including non-team; indeed it's obvious by design. But it should be an option, and I was trying to say that you could still input any user, just not have it auto-complete to any user.

    I've noticed that the team-mates are prioritized, but I've also noticed that it takes a while for them to turn up as the topmost. For example, in our team there is a "trent", if I type "tr" only, he is not the first person I see.

  3. Erik van Zijst

    For example, in our team there is a "trent", if I type "tr" only, he is not the first person I see.

    That's because autocomplete requires a minimum of 3 characters.

    Edit: I take that back. It's more subtle than that, but I'll have to look into that first.

  4. Noon Silk

    That's because autocomplete requires a minimum of 3 characters.

    Edit: I take that back. It's more subtle than that, but I'll have to look into that first.

    Yeah, it seems to require more than 2 the first time, and subequent times it doesn't ...

  5. Erik van Zijst

    It's wildly considered that having a list of users is a security flaw in that it provides a source of valid usernames which can have some value if someone wants access to just any valid account, instead of a specific account, which is a standard technique.

    You're not accessing the account, you'd be adding them as a PR reviewer. If you mean that the user now has knowledge of the fact there exists an account named xxxx is a security issue, then I'm not sure I agree. We want user accounts to be as visible as possible in the spirit of collaboration. Google also provides a great source for discovery.

  6. Noon Silk

    If you mean that the user now has knowledge of the fact there exists an account named xxxx is a security issue, then I'm not sure I agree. We want user accounts to be as visible as possible in the spirit of collaboration.

    Indeed, I do mean this.

    The basic idea is that instead of trying one account with 100 passwords, I could try 100 accounts with 1 password; the latter is clearly not targetted; but it might still be useful for an attacker, and the autocomplete interface (and probably the associated api's which I'm sure could be easily coerced to return all valid users of bitbucket) is offering up this information.

  7. Erik van Zijst

    the autocomplete interface (and probably the associated api's which I'm sure could be easily coerced to return all valid users of bitbucket) is offering up this information.

    Yep, for sure. Still, we strongly feel that crippling autocomplete (and all other things that expose information like this) would limit collaboration.

    Another example is the repo search bar (top right in the header). The whole purpose of that thing is to help you discover repos and each repo slug automatically contains the owner's username. The repo search page is another feature that relies on discoverability.

  8. Noon Silk

    Yep, for sure. Still, we strongly feel that crippling autocomplete (and all other things that expose information like this) would limit collaboration.

    Sure, okay. Perhaps users could opt-out of discoverability?

    But I understand your position.

  9. Erik van Zijst

    Perhaps users could opt-out of discoverability?

    I could raise an issue for that, but for users that only have private repos, there's really not much being leaked, except the fact that they exist. However, removing them from autocomplete would still not make their landing page disappear, or stop the Internet from indexing them.

    A broader, more controversial approach might be to allow users to make their entire profile invisible (bitbucket.org/xxxx would 404), but I doubt anyone on our team would support that (still, feel free to raise it as a separate issue to start a discussion and allow others to vote).

  10. Nicolas Venegas

    At the moment, the query for users in autocomplete will search across all Bitbucket users. If your teammates happen to be in the list of results that match the query, we surface them to the top.

    It would be preferable to first search only your teammates. If there are not enough results, then we should fall back to searching the entire Bitbucket user base. Alternatively, we could provide an option (checkbox, perhaps) to limit the search to only your teammates.

    I will look into improving this over the next couple of days.

  11. Log in to comment
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.