Users should be able to make private branches of public projects

User can have private branches for public projects, they need to ask so that the reason are understood.

On Thu, 2010-02-25 at 18:01 +0000, Curtis Hovey wrote:
> User can have private branches for public projects, they need to ask so
> that the reason are understood.

So, should it be "users should be able to create arbitrary private
branches"? If that's available, how do I sign up? :)

  --Ted

Well, we can make private branches for people. All you need is ask and have a legitimate reason to need a private branch. If users could casually create private branches, it would get abused.

Actually we are considering allowing anyone to create a private branch. It is just a case of prioritizing the work.

I've talked with poolie about this about adding something like bzr push --private lp...

Although not sure how that'd work in practice.

Knowing that you need to specially ask someone and wait for them to respond is not really a good solution.

Tim if you add an api for this we can call it.

On Fri, 26 Feb 2010 13:12:20 Martin Pool wrote:
> Knowing that you need to specially ask someone and wait for them to
> respond is not really a good solution.
>
> Tim if you add an api for this we can call it.

There is an api, but the point is that not everyone is currently allowed to
make any branch private. It is restricted by which team you're in, not by ui
not implemented.

We are considering a broad stroke across the privacy to just allow people to
make their own public branches private.

On Fri, 2010-02-26 at 00:51 +0000, Tim Penhey wrote:
> On Fri, 26 Feb 2010 13:12:20 Martin Pool wrote:
> > Knowing that you need to specially ask someone and wait for them to
> > respond is not really a good solution.
> >
> > Tim if you add an api for this we can call it.
>
> There is an api, but the point is that not everyone is currently allowed to
> make any branch private. It is restricted by which team you're in, not by ui
> not implemented.
>
> We are considering a broad stroke across the privacy to just allow people to
> make their own public branches private.

Just to clarify, I think it's important that it's not making "public
branches private." It's about making sure that there is never a public
branch at all. It should exist as public and then get converted.

Also, I'm still a fan of the URL based distinction more than a command
line one as it'll show me everytime I push or pull that the branch is
private. Plus, being a command line option implies that it should be
part of Bazaar. The reality is that Bazaar doesn't know anything about
public/private, it isn't important to Bazaar. It is strictly a
Launchpad feature.

Ted, just a sanity check: did you mean "It should NOT exist as public and then get converted." ?

On Tue, 2010-05-04 at 21:07 +0000, Karl Fogel wrote:
> Ted, just a sanity check: did you mean "It should NOT exist as public
> and then get converted." ?

Yes, sorry, typo. Thanks for catching it :)

I think this relates to the entitlement issues that commercial projects face. I would like to add/revise the security checker for making a branch private. I think there is a common set of conditions we could agree are sane. This is my list of conditions that I think should permit a user changing a branch to private:

* The branch is owned by a private team (The branch is already implicitly private)
* The project has privacy enabled and the user is in a project role
* The branch is linked to a security bug the user can access
* the branch is linked to a private bug the user can access

Further discussion with Curtis and the team working on implementing disclosure has resulted in Curtis' list of conditions to be revised to remove the project roles clause. So a user will be allowed to change a branch to private if:

* The branch visibility policy allows it (for legacy support until BVP is removed)
* The user is special (admin or bzr expert)
* The branch is owned by a private team (The branch is already implicitly private)
* The branch is linked to a private bug (embargoed security, user data, proprietary) the user can access

"Change to private" means setting the information type to a private value (embargoed security, user data, proprietary). Otherwise, just the public values are allowed (public, unembargoed security).