Re: [Monotone-devel] RFE: Hard Barrier Between Branches in Netsync

[Ulf Ochsenfahrt]

Thomas Moschny wrote:
> On Friday 02 March 2007, Ulf Ochsenfahrt wrote:
> > Second, it would lead to (potentially) lower efficiency. If the user has
> > new revisions which are children of revisions that he does not
> > officially has read-access to, then he has to also transmit the parent
> > revisions, even though these may already be present in the other
> > database. I do not expect that this would happen often. One could even
> > argue that this can only happen when the access rights are incorrectly
> > configured. After all, how can a user know of a revision that he doesn't
> > have read-access to?
>
> What is the problem here? During netsync, one peer (the server) can tell the 
> other peer (the client) about *IDs* (i.e. hashes) of all the revisions it 
> has, regardless of whether it is allowed to tell it about the *contents* of 
> those revisions? Current netsync probably cannot handle that, because it aims 
> at clearing out all differences between the revisions sets of both peers, 
> after having determed them. In the case above, the client could have only 
> some of the revisions it is actually not allowed to have but not all, so it 
> would ask the server again and again.


Consider the following case:
Branch    A | B
Revision  x |

You have no access to A, and both read and write access to B.

Right now, you can write a certificate stating that revision x is part 
of branch B. If you have read access to B, then you can read revision x 
(and all its ancestors), even if it was originally in A to which _you do 
not have read access_.
Branch    A | B
Revision  x | x

One solution is to block branch certificates. However, you can still get 
the contents of revision x. You do this by creating a revision x' that 
is a child of x, and put that in branch B. Then netsync will 
automatically tell you the contents of x in A, to which _you do not have 
read access_.
Branch    A | B
Revision  x |
           \|
            \
            |\
            | x'

So, the correct solution is to block both branch certificates and 
revisions that have a parent in a branch to which you do not have read 
access.

However, what happens if you got revision x from elsewhere, and you want 
to create x' in B?

You can do this by proving to netsync that you know the contents of x. 
In fact, you should also have to prove that you know the entire history 
of x, because you just effectively published it on branch B.

There's the catch. Giving a revision a branch certificate in another 
branch gives allows anyone with read access to that branch access to the 
entire history of that revision.

> Maybe this issue will go away if we change netsync to use a dag-based 
> refinement, as proposed by Timothy here: 
> http://lists.gnu.org/archive/html/monotone-devel/2006-09/msg00124.html

And that is exactly what dag-based refinement is supposed to solve: if 
you use the branch name to select a revision, then netsync currently 
also selects the entire history of that revision, even if it isn't on 
that branch. And if the other side didn't select the history of that 
revision, then you have a performance problem.

However, that assumes that you have read access to those revisions.

Cheers,

-- Ulf

smime.p7s
Description: S/MIME Cryptographic Signature