Re: [Monotone-devel] Re: Policy branches?

[William Uther]

On 17/04/2007, at 12:38 AM, Bruce Stephens wrote:

> I edited <http://www.venge.net/mtn-wiki/VersionedPolicy/Archive> to
> include the links not already there.

I just went and read all of this, and I have some comments:

My thoughts on what a policy branch might be there for:

Currently:
  - Each person who runs a server gets to decide which keys can send  
them revisions (and get revs from them), but the revisions sent could  
be signed by anybody (and revs received can be sent to anybody).
  - Each user decides which certs should be trusted, and which revs  
should be trusted based on those certs
  - Other stuff: e.g. there is no versioning of the 'live' branches  
in a repository.  i.e. I can't say that I don't want 'mtn ls  
branches' to list will.temp_branch any more.

This has at least one major problem:

  - We want a mechanism whereby everyone in a group can share trust  
information.  e.g. A central monotone repository can keep a list of  
keys trusted for the 'net.venge.monotone' branch and everyone who  
wants to use that same list of keys, can.

Note that when I say "A central monotone repository can keep a list  
of keys", I really mean that "the monotone admin" has added that key  
to their list, so it might be better to say "trusted by njs".  But  
then we don't want a bottleneck person, so we then get into the  
situation where I want to say "trusted by someone trusted by njs for  
net.venge.monotone".

Next use case: We don't want to say "trusted by njs", or "trusted by  
will".  We don't even want to say "trusted by njs or will" (which I'm  
assuming means the union of njs's trust file and Will's trust file),  
what we want to say is "trusted if it is listed in the trust file X,  
and that file is signed by njs or Will".  Or even, "trust any key  
listed in trust file X if that file is signed by someone trusted by  
njs".  I don't think that we need this sort of language complexity  
initially :).  (That last example allows njs to maintain a list of  
admins that can maintain the complete list of keys.)

I think it is a mistake to try and have a centralised view here.   
There could well be two different camps for committing to  
net.venge.monotone... and that's ok.  Given that things will be  
different in different camps, it seems that the only 'default trusted  
person' or 'trust seed' for each server is the admin of that server  
(or whatever was installed locally on that server).  The real goal  
here is to give that admin a way to delegate trust.  And that  
delegation must be somewhat able to be further delegated.

Things get a little tricky because trust can be revoked, and  
communication is asynchronous.

Imagine we have something similar to a normal monotone branch, but  
with a collection of files describing who trusts what (to do what):  
"njs trusts these keys for monotone", "Will trusts these keys for  
monotone", etc...  Each server then has a config file that says  
something like "trust njs's view on who can commit to monotone".   
Njs's file could say "trust anyone trusted by Will, except Dastardly  
Dan".

What is interesting here is that it is the statements by people about  
who they trust that need to be signed, bBut monotone doesn't sign  
individual files.  For the moment I'll just say that I'll trust  
someone's last "trust file" stored in a revision was signed by them.   
There is probably a more efficient representation.

So, how do you verify trust?  Well, if the server config says "trust  
njs", then you search back in the policy branch until you find a rev  
signed by njs - you then trust the stuff said by njs in that file.   
This is a graph search for the key.  Delegations add links in the  
graph.  "except" clauses prune links for specific people.

To revoke a key, you simply remove it from your list of trusted keys,  
or add and except clause for it.  You will not trust any revs by that  
person any more.  I'm assuming that you will still trust descendants  
of untrusted revs, if they are signed by someone you DO trust.  Note  
that this decouples the time on the policy branch from the time on  
the source branch.  This seems like it is a good thing (well, I'm not  
sure it is possible to have things any other way, so we might as well  
make a virtue of necessity).

In this model, once you delegate trust to someone, you delegate trust  
to them for all time, until you revoke it (and that revocation  
reaches the machine doing the checking).  It seems that the only  
alternative is to delegate trust to a particular revision of someone  
else's trust file (that other restriction could be explicit in terms  
of listing a rev ID, or implicit in that it must be in an ancestor  
rev of the rev you've signed).  If you have that restriction then it  
makes delegation much less useful.  You want to be able to say "John  
is going to keep the list of people working on his branch up to  
date", without having to rubber-stamp the changes when they're made.

Comparison with other people's ideas:

I don't understand njs's merging based idea.  It seems to be based on  
the concept of a single statement of what is trusted.  I find this  
problematic because it doesn't say who can change that trust.  The  
concept of the policy branch controlling who can change the policy  
branch itself scares me.  I don't really care how the merging  
happens, as long as it is signed by someone I trust when done.  Being  
able to trust a trust-file signed by any of a number of people allows  
you to just use a normal file and merging here.

Paul Crowley's idea seems pretty close to mine.  He has a much more  
fleshed out concept of the layout (perhaps a little complex for a  
first pass though?).  He has the concept of trust chaining (I have  
more complex trust chaining statements, but here mine is probably too  
complex for a first implementation).  He bases his trust for a branch  
in a 'user branch', but then says he sees that being in  
the .monotonerc file - this is basically the same as my 'server  
config file' for rooting trust.  I had assumed that there would be  
one 'policy branch' with a bunch of files - one file for each person  
stating a policy.  Paul has one branch for each person stating a  
policy.  Having a branch for each person stating a policy means that  
each branch is very simple and can be signed separately.  This is a  
difference in implementation detail, and I'm sure we could do better  
than either proposal.

I don't really understand Tim Brownawell's model... my closest guess  
being that it is like Paul's and my ideas, but using "statements"  
rather than files or branches as the units that get signed.  Not sure  
what practical impact that has.

How that made sense to someone.  The end result is that I think  
Paul's idea is a good place to start.  :)

Be well,

Will            :-}