monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] policy branch proposal (rough draft)


From: Timothy Brownawell
Subject: [Monotone-devel] policy branch proposal (rough draft)
Date: Sat, 16 Sep 2006 11:04:51 -0500

This is fairly heavily based on
http://www.venge.net/monotone/wiki/VersionedPolicy .

Here I'm assuming that we want to allow multiple projects (trust seeds)
per db. I think that not allowing this is overly restrictive and
probably unworkable, and especially not workable for shared hosting.

This allows for both hierarchical branch renaming and project renaming.
It also allows for project names to be forced, in case of a collision.

It allows for anyone to merge the policy branch, as long as they have
permission to edit any files that have conflicts.

====================

policy branch:
/policy-root    -- file with the base policy rules; delegates
                -- authority (including the authority to change
                -- this file) to certain users
/name           -- file containing the default name of this project

/users/         -- directory containing user directories
/users/foo/     -- user directory for 'foo'
/users/foo/rules        -- file with policy rules authorized by 'foo'
/users/foo/keys         -- file listing keys that 'foo' owns
/users/foo/*            -- random other user data (name, IRC nick, ...)

/servers/       -- like /users/, but for servers instead of people
/servers/foo/keys       -- keys that this server might use
/servers/foo/admin      -- says who can change this server's info;
                        -- should be whoever has shell access to the
                        -- server process
/servers/foo/branches   -- what branches are served (globs/ids/etc)
/servers/foo/address    -- DNS name / IP address of this server
/servers/foo/rules      -- a *copy of* the rules this server uses to
                        -- accept/drop incoming revisions; for sanity
                        -- this should not be less permissive than
                        -- project commit policy. The *actual* rules
                        -- are in a file on the server; this is just
                        -- informative, so people know what to send
/servers/foo/*          -- random other server data

/branches/      -- representation of the branch hierarchy
/branches/foo/  -- directory for branch foo
/branches/foo:id        -- used in branch certs
/branches/foo:status    -- used for marking branches as finished
/branches/foo/*         -- random branch metadata
/branches/foo/*/        -- subbranches of foo
/branches/foo/bar:import        -- (instead of having :id) give the id
                                -- of another projects (policy branch),
                                -- whose branches are to be included
                                -- under this name

/keys/          -- directory holding key data
/keys/address@hidden    -- pubkey packet
/keys/REVOKED/  -- directory that revoked keys get moved to
/keys/REVOKED/<id>/pubkey       -- revoked key
/keys/REVOKED/<id>/valid        -- valid certs signed by that key


Should /users/*/keys and /servers/*/keys be hashes or names?

Files under /keys/ are immutable. (possible exception for
REVOKED/*/valid ?)

/users/foo/rules is *only* editable by foo. /servers/bar/* is *only*
editable by the server admin. Revisions which violate this are ignored
completely (dropped at sync time?) as inconsistent, and there is no
commit switch to allow such commits.

/users/foo/keys should probably be editably by (some) admins (what if
your key gets lost, say by disk failure?), but how to prevent them
impersonating someone? Maybe say that if you hold any private keys for a
user, and the keys file for that user is edited by someone using a key
not listed in the pre-edit version of it, monotone will print a big fat
warning for you?

/policy-root is only editable by people given that permission. If
someone else edits it (this requires a commit switch to enable), there
is a silent fork. If two admins edit it to exclude eachother, there is a
noisy fork (all users are informed and must choose which side to
accept).

The previous three paragraphs use the permissions and identities from
the parent revision. Other checks use those from the current revision.

If a file other than /policy-root is edited by someone without
permission, that revision is silently ignored (dropped at sync time?) as
inconsistent. Such commits are refused, and there is no override switch
(the "override" is to edit /policy-root to give yourself permission).


Anyone can do a clean merge of the policy branch. Anyone can do a
non-clean merge of the policy branch, provided that only files they are
permitted to edit have conflicts (this includes automatically resolvable
conflicts). Specifically, a node (file/dir) in the policy branch is
acceptable if at least one mark from each set (name, content, each attr)
is from a revision signed (branch cert) by someone authorized (or enough
of the right someones) at that time to edit that node; a revision on the
policy branch is acceptable if all its nodes are acceptable. Once we
have the subgraph of acceptable policy branch revisions, we can pick
which one to use (the simplest way is "use the head; if there are
multiple heads, throw an error", but this wouldn't work for the
Alice/Tom situation in njs' bootstrapping email.).


branch certs would be of the form "<project id> <branch id>". branch
certs for policy branches are "<project id>" (ie, empty branch id).
There are db vars giving the trust seed for each project id. These are
made available over netsync, but not routinely actually sent (or maybe
the are always sent, but not stored; they just cause the client to print
a message if they differ). Each policy branch has /name that says what
name it wants; if two projects want the same name an advanced user could
override this with a db var project id <=> project name.

branch names would be displayed as <project name>.<branch name>,
possibly with the ability to omit the project name if the project is
already known.

====================

commit should take a --new-project=(given|wizard) switch, saying that
either what is being committed is a new policy branch and should be
given a new project id, or that what is being committed is a normal
branch, and monotone should ask a few questions and generate a new
policy branch to use. --new-project=given is also what you'd use for a
friendly fork. Ideally it would also be (eventually) used on one side of
an antagonistic fork, so both sides could be trusted in the same db.

There should also be a "mtn new_project" command, that just asks
questions and generates a new policy branch.

Netsync should allow queries of "what project id does this name map
to" (also the "what trust seed does this project id map to" mentioned
earlier). These would be useful for initial pull, or if the user wanted
to defer to the admin of their chosen netsync server in choosing a side
of any antagonistic forks.


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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]