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

[Nathaniel Smith]

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.

Also, I couldn't think of any real advantages to doing things this
way.  Consider a modified Alice/Mallory situation:
     A
     |\
     B \
     |  C
     | /
     |/
     C'
With your proposed rule, this again gives the confusing situation
where B and C' are both candidates, even though C' is a child of B.
So I'm not sure what we win by sticking only to edges.

> GENERAL REMARK
> --------------
> Oh, and I don't like the fact that everyone who ever had commit
> access could always stall the project.  
> 
> I want that if I distrust Mallory, that all revisions signed
> by him will NOT enter my database.
> 
> Now I understan that the following scenario could happen:
> 
> 1 - mallory has commit access to the project according 
>     to current trust rules
> 2 - Mallor kicks everyone out and syncs with the project 
>     database
> 3 - Nobody can do anything anymore.  Not even fork.
> 
> However, I do think that these situations should be resolved
> by the owner of the project database.  Just leave commit 
> access to the database open always, just so we can keep
> on working in this event seems not the right approach to me.
> 
> Also I don't like it that the decision who to trust, by picking a new
> trust seed, is forced on all users.
> When I am a user, I more or less trusts the owner of the database I sync with.
> He can do whatever he wants with his database, if he is evil, he can just
> stuff the database with useless data or just take it off-line.  
> So I have a basic trust in the owner.  If mallory wants to fork and
> Alice the owner does not agree, let mallory start his owner server
> and I will connect to that one.  

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.

Besides which, part of the point of these rules is to serve as a
deterrent.  If Mallory can get away with stealing the project like
that, he might do it.  If he knows that the most he could manage is to
cause everyone a minor hassle (and in the progress make it very
unlikely that anyone will join his fork), the motivation is reduced.

It is true that in practice, for many projects, ultimate power rests
in the hands of whoever owns the box that the project lives on.[1]
If you want to emulate this in something like the policy branch
framework, then probably you can -- there's nothing that says the
project founder ever has to give anyone else admin-level access -- but
it does at least make obvious that this means there's a single point
of failure, which is a distressingly common situation?

Note also the end of my email where I say that we may need the ability
for some admins to be so awesome that they can override rule changes
that they have never seen; this may be what the original founder has.
I don't know how to make that work, but it looks like we might have
to figure it out...

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.

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.
  -- 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.)
  -- 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.
  -- 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.
  -- 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.

-- Nathaniel

[1] Well, _real_ power generally lies in the social structure of the
    group, and who will listen to who.  But you still need a solid set
    of rules for how computers should enforce permissions day to day.

-- 
The Universe may  /  Be as large as they say
But it wouldn't be missed  /  If it didn't exist.
  -- Piet Hein