[Monotone-devel] [RFC] versioned policy -- introduction

[Nathaniel Smith]

I think it's about time to start getting more into the discussion of
how this thing we've been calling "versioned policy" will work.  So,
I
wrote up an overview of where we're starting from.  I don't think
anything here will be new to you, if you're, uh... someone who's been
obsessively following every discussion of this on IRC etc. for the
last several years.  This is, however, I think the first time it's
laid out, and I'm hoping to send some more notes like this getting
into more details, so this is good background.

This is, hopefully, the last major architectural change in monotone,
and the most important missing feature, so it might be worth reading
:-).

Goals
-----

There are several problems with the current monotone design, that
apparently cannot be solved without the addition of a new kind of
per-project versioned metadata.  In particular:

  * Our key names are required to be globally unique over space and
    time.  This turns out to be very bad; we need to make it possible
    to get rid of old keys, and create new ones.  That each key used
    "burns a hole" in this global namespace makes our current
    approach unsustainable in practice.
    -- Solution?: create some kind of local, per-project namespace,
       within which keys have names.  The bindings of name to key
       should be shared by all members of the group, but should be
       allowed to change over time.

  * We need some way to manage "commit" permissions.  For now, people
    have been faking this functionality using netsync permissions,
    but this approach is deeply unsatisfactory.  A major design goal
    of monotone is to make communication as noncommittal as possible;
    to make it so you can always, painlessly and without worry, send
    information around.  Not only that, but netsync permissions don't
    really work right for this anyway; we have all these lovely
    signatures and audit trail stuff, and it's completely orthogonal
    to the netsync permission system that everyone uses in practice.
    -- Solution?: create some kind of local, per-project ACL list,
       which is modifiable by some users (controlled by the ACLs),
       which everyone locally uses to decide which certs they believe
       in.

Once we have this kind of project-level versioned metadata, there are
a number of other interesting uses we might find for it.  For
instance, you could make branch names a similarly project-local
namespace, support branch renaming, store extra branch metadata like
"branch parent", "branch status", put tags in here to get movable
tags, etc.

For a first pass, though, I want to talk about the simplest thing
possible (because it gives me the fewest chances to screw up :-)),
and
then we can build from there.  So let's just think about:
  * how to store keys
  * how to grant/revoke permissions of the form "key X may commit to
    branch Y"
(Again, one might want to define trust for other cert types, and make
such commit permissions conditional on what files were modified, and
yada yada, but let's ignore that to start.)


Rough plan
----------

This is a system for delegating authority, and all authority reposes
initially in the user of the system.  Therefore, we have to start
with some affirmative action on the part of the user, stating where
and how they delegate their authority.  We want this action to be very
simple, and to last for a long time -- basically, the user should
experience this as something they do once when they join a project,
and then forget about thereafter.  (In practice it will probably even
happen as part of initial pull, but UI is a separate issue).

We also, for pragmatic and usability reasons, want to re-use all the
great machinery we have for managing and versioning trees.  So here's
the idea: create a tree with ACLs and keys and such in files.  Check
this in to monotone as a revision.  A user grants permission by
stating which revision they are delegating to.

Of course, this would be boring if they were just delegating to that
_particular_ tree, because they'd have to redo things every time
anyone joined or left the project and permission changed.  But,
monotone gives us a natural way to express changes to a tree -- child
revisions.

We call the user-specified revid the "trust seed".  The "seed" part
emphasises that we are not (necessarily) trusting the tree we point
to in particular.  Rather, one of the things a tree should have ACLs
for, is specifying who is allowed to commit _new trust trees_.  The
simplest way to do this is to put the trust trees in a special branch,
and specify commit access to this branch like any other branch.

So, to determine the actual trust rules in affect at any given time,
we:
  -- start from the trust seed
  -- walk down the revision graph from it, at each step using the
     trust rules in our current revision to decide whether we can go
     to the next revision
  -- finally reaching the tree that contains the policy we will
     enforce
There are some subtleties in exactly how one might do this walk,
which I'll defer to another, more technical, note; but hopefully this
gives the basic intuitions behind the approach.

Questions, comments?

-- Nathaniel

-- 
Linguistics is arguably the most hotly contested property in the academic
realm. It is soaked with the blood of poets, theologians, philosophers,
philologists, psychologists, biologists and neurologists, along with
whatever blood can be got out of grammarians. - Russ Rymer