[Monotone-devel] Re: [RFC] versioned policy -- bootstrapping

[Wim Oudshoorn]

Nathaniel Smith <address@hidden> writes:

> On Sun, Sep 10, 2006 at 02:01:12PM +0200, Wim Oudshoorn wrote:
>> Nathaniel Smith <address@hidden> writes:
>> > Call a revision R with cert C "trivially reachable" from some other
>> > revision S, if R is a descendent of S, and C is a cert trusted by S
>> > which claims that R is in the policy branch.  Trivial reachability
>> > defines an overlay graph on the revision graph, where you draw an edge
>> > between two nodes when one is trivially reachable from the other.
>> > It's the heads in _this_ graph which form our candidate set, and full
>> > reachability is simply equivalent to reachability in this graph.
>> 
>> Hm, why like this?  What about the following:
>> 
>> Let G be the DAG that is the monotone repository containing the policy
>> revisisions.
>> 
>> let T(G) be the trust DAG of G.  That is, let the  nodes of T(G) be the
>> nodes in G and the edges of T(G) consist of:
>> 
>> Edges (T(G)) := {R -> S | if R->S is an edge in G AND R trusts S}
>> 
>> Now we do more or less what you propose, 
>> let TF (the trust frontier) be defined as
>> 
>> TF (S, G)  = {all revisions R in T(G) such that there is 
>>               a path from S to R in T(G) and R does
>>               not have descendents in T(G)}
>> 
>> Or in other words TF (S, G) consists of all maximal elements
>> in the PO-set induced by T(G) greater than S.
>
> Right, this is the same algorithm, except that you only consider
> jumping from a revision to its immediate children, as opposed to all
> descendents.  One can do things this way; the only reason I didn't
> suggest doing it that way is that it violates the general rule in
> monotone that the difference between child and descendent doesn't
> matter.  For instance, suppose you use "propagate" while managing a
> trust branch, and it decides to do the fast-forward just-issue-a-cert
> sort of merging.  Normally, that's correct, but for a policy branch it
> would fail.  We could teach propagate to have special cases for policy
> branches... ugh.

Oh, For me the above is simpler to reason about :-)   
I guess the other scheme reasons better for you.  I don't think
it will make a material difference one way or the other.
[And I don't see actually we adding certs for the fast forward
propagate would make a difference.  But I don't really want
to think about that.]

> Hmm, you think that a project forking, admins going separate ways,
> etc., is something that users could ever usefully ignore?  My
> intuition is different; in most (but not all) cases, one side is
> clearly to be ignored, but it's a toss-up whether that's the side that
> ends up with the original domain name and hosting.

First of all, I think it can be ignored some of the time :-)
But anyway.  I do not think monotone trust system is the place
to fight over forks.  Because you have:

A - polite forks.  In this case the security measures
    don't really matter.  Mallory will just announce it is forking
    and how where etc. to access the fork.

B - hostile forks.  Well.  I think there is generally a lot more
    to fight about than just commit control to monotone and
    monotone permissions are not the way to resolve this.


> We can and will have netsync permissions as well.  We just don't want
> to have to rely on them to give us any security properties, so we
> ignore them for now.

I disagree.  I am all for the distributed nature, and I agree
that there are two issues:

1 - trust statements over particular revisions that are in
    my database.
2 - configuration of what I want to end up in my database.

But if we are talking about hostile scenarios, ignoring point 2 and
just asssume we can fix it with 1 feels wrong to me.

>
> Also consider:
>   -- A large project puts up multiple netsync servers on DNS
>      round-robin.  each server is contributed by a different
>      organization, and they do not trust each other enough to do this
>      if it creates a security exposure.

So, what kind of security exposure?   If you are worried about that
I would more concentrate on the netsync security.  If I as an organization
do not trust my peers, I definitely want to say what goes into my database
and what leaves my database.  

For example.  I am organization A and want to avoid that my private
changes to the project leak to my competitor B.  
I would not trust B to be nice and observe the trust seed.  I expect
them just to checkout what is synced regardless of trust.
So I do NOT want to sync certain branches with the outside world.

Other excample if I as A do not trust my competitor B not to infect
the my code.   I have the following problem:

1 - I do not trust revisions coming from B.
2 - I do not trust any revision that is a descendand of a revision coming
    from B unless examined by me A.

So this asks for a policy that is particular to me A.  And this trust
policy I do not want to leak to the outside world.  It is useless to them
anyway.

Another example I as organization do not trust my peers B 
because illegal material could end up on our computers and 
in a recently started lawsuite B claims we used this illegal material.

Again I do not want the material on our databse in the first place.

>   -- A small project has its server go down, and no-one can get at it
>      to fix it for some time.  Some random on the mailing list starts
>      up a server and offers public access so work can continue while
>      the project admins are sorting things out.  (This happened to
>      monotone in the early days; development did not slow down.  OTOH,
>      projects as large as GCC have ground to a halt for multiple days,
>      because their VCS server crashed and there was nothing to be
>      done about it.)

No problem with that.  I like this aspect of monotone very much.  
But uh how is this relevant?  Nothing in any proposal is interfering
with this part is it?

>   -- I don't entirely trust my hosting company (which is probably a
>      good idea, hosting companies can and do go insane at some
>      hopefully small, but non-zero, rate).  I don't want to give them
>      the ability to screw around with my project's history, even if
>      they are the canonical storage place for it.

Yes?  No argument here.  But still they can screw with the database
all the want.  Delete all the trust revisions, insert new trust revisions
change the seed etc.  

>   -- A random on IRC says "I think I have a fix for bug#1234, I just
>      pushed it to my server <address>".  You want to be able to pull
>      from that server, without giving him the ability to stick stuff
>      into random other branches of yours.

Yes indeed.  I don't want this random stuff in my database.  
I want to decide my policies, which can be fastly different than
the projects policies.  

>   -- Future versions of monotone that usefully use methods other than
>      netsync for communication.  mtn-dumb, packets sent to a mailing
>      list... it would be nice not to have to redo security analysis in
>      all of these cases.

Of course.  I was more using netsync as a placeholder for data going in and 
going
out to other computers/users.

I get the feeling that what we want does not differ so much, and somehow
I miss the point of what you are trying to say.  

Also I have this instinct that this is becoming too complicated, 
and will not solve the real problem.  Unfortunately it is just gut feeling :-(

I find it hard to get my head around and I find it hard to get the problem
clearly defined.


Wim Oudshoorn.

P.S.: I really like the freedom of monotone.  So keep up the good work!

P.P.S.: What about having an external file with trust rules?  
        No automatic updating, no merging no mysterious change
        in policy after sync'ing with a database.
        Just once in while you have to update this file.  But this
        should only be done rarely.

        You could even put the database and branch information in this file 
like:

        FOO.monotone-project
        --------------------
        project-name: FOO
        sync-server:  netsync.server.com
        branch-pattern: FOO.*
        trust-policies: 
                        (Foo.STABLE allowed address@hidden)
                        (Foo.*      allowed all)
                        (Foo.*      disallow address@hidden)