launchpad-dev team mailing list archive

[John Meinel <john@xxxxxxxxxxxxxxxxx>]

Unfortunately I don't have a great view about the security levels. I will
say that it is uncommon to have branches stacked more than 1 deep. It may
happen a bit with packaging branches as we stack on newest. I might argue
to just disallow stacking on a stacked branch if things aren't public.
Would that help? People rarely (ever?) manually request stacking LP just
informs bzr to default stack on the dev focus.
For a first pass I would shoot for fail safely and with a clear message,
rather than try to hand the myriad of cases.

The other option is that if things are ordered, no branch can be stacked on
a target that is more private than itself. If users could create private
branches themselves you wouldn't need the "transient" private flag. They
just get created as private directly.
If you create a branch via the web UI we should make sure the branch is
created stacked.

John
=:->
On May 18, 2012 7:30 AM, "Steve Kowalik" <steve.kowalik@xxxxxxxxxxxxx>
wrote:

> Hi,
>
>        Currently, Branch has two fields which determine if the branch is
> private -- explicitly_private and transitively_private. A private is
> explicitly_private if it has been marked as private, and it is
> transitively_private if it itself is public, but is stacked on a private
> branch.
>
>        As part of the Disclosure project, Purple are working on migrating
> Branch to using information_type -- much like we already have for Bugs.
> The types of information are Public, Unembargoed Security, Embargoed
> Security, User Data, and Proprietary. We already moving to being able to
> control who can see the different types of information with the +sharing
> page.
>
>        The information_type column is fully populated on all three
> instances
> of Launchpad, so we can start switching model code to depending on it
> rather than the two private columns.
>
>        One thing that is currently causing issues is how do we deal with
> stacking and information_type? It's clear that any type of information
> can be stacked on top of a Public branch -- in much the same way that we
> can have private branches stacked on public ones currently.
>
>        This whole thing gets murky when you consider say, branch A, which
> is
> Embargoed Security branch stacked on branch B, which is User Data? It's
> clear who has access to branch B, but who has access to branch A? Purple
> has decided that this situation is not allowed, since it isn't clear.
>
>        The other situation which murks up the water quite a lot is when you
> consider the following -- branch A is public, branch B is stacked on A
> and is Embargoed Security, branch C is stacked on A and is User Data,
> and branch D is Embargoed Security and stacked on B. If we then change B
> so it stacks onto C, what should happen? We've already decided that
> Embargoed Security on top of User Data is wrong, and if we change the
> information_type of B and D to User Data, we could end up disclosing the
> contents of the branches to other people.
>
>        Thoughts? Comments? Things that I've haven't made clear?
>
> Cheers,
> --
>                                        Steve
> Launchpad Developer
> Canonical, Ltd
>
> _______________________________________________
> Mailing list: https://launchpad.net/~launchpad-dev
> Post to     : launchpad-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~launchpad-dev
> More help   : https://help.launchpad.net/ListHelp
>