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

[Timothy Brownawell]

On Wed, 2006-09-06 at 23:28 -0700, Nathaniel Smith wrote:
>   * 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.

How does this interact with how keys are used for netsync (especially if
you're syncing more than one project)? Would it just be that instead of
--key=keyname you use --key=project/keyname ?

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

If there's a lot of branching going on, managing all branches in a
project with one tree *will* cause divergence. As we've seen on
mainline, the person who does a merge may not be one of the people who
caused the divergence; with some of the discussed rules for management
branches, this would not be possible and the multiple heads (an error
condition for these branches, right?) would remain until noticed by
someone with the correct permissions to do the merge. This could
potentially take quite a while.

>   * how to store keys

Probably a file with lines mapping key_hash <=> key_name . The actual
key data could still be in the db as it is now, minus the name column.
Certs would drop the key name field, and only use the key hash.

>   * how to grant/revoke permissions of the form "key X may commit to
>     branch Y"

Revoke would probably want to include a frontier, so revisions known to
be committed before whatever problem came up could still be trusted.

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

We might want some special commands for working with the management tree
without actually having to check it out? (mtn grant <key> <branch
pattern>; mtn revoke <key> <branch pattern> [frontier (defaults to
current heads)]; etc)

Tim
-- 
Free (experimental) public monotone hosting: http://mtn-host.prjek.net