[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: Policy branches?
From: |
William Uther |
Subject: |
Re: [Monotone-devel] Re: Policy branches? |
Date: |
Tue, 17 Apr 2007 14:33:38 +1000 |
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 :-}