[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Policy branches - first steps
From: |
Paul Crowley |
Subject: |
[Monotone-devel] Policy branches - first steps |
Date: |
Fri, 16 Feb 2007 19:28:18 +0000 |
User-agent: |
Icedove 1.5.0.9 (X11/20061220) |
As Graydon points out, we'll learn a lot more about what direction to
take policy branches by implementing them than by thinking about them.
I propose we make an incremental step that will get us moving, and that
we'll be able to build on later.
So here are the corners I want to cut to get something out now. These
are all things we'll want to fix in a later revision.
- Use a very simple rule to decide validity - a revision is valid if
it's signed by one of the valid keys, no matter what its history.
- Don't try and support namespaces or branch renames - use the existing
branch names
(this also means that we'll enforce a tree through the namespace)
- Don't try and use policy to give users names - use existing
infrastructure for that
(we will want to fix this, but policy branches will be useful before
we do)
- Use a dumb implementation of ACLs
I've checked in some sample policy branches. I haven't used the names
these branches would have in a real implementation, though.
"net.venge.monotone.experimental.policy-branches.examples.example-user-policy"
- should really be called "address@hidden" or another user name
- This might be a user's personal policy branch. It delegates all
authority on all Monotone branches to
"net.venge.monotone-policy.founder" as signed by Graydon.
"net.venge.monotone.experimental.policy-branches.examples.monotone-policy.founder"
- should really be called "net.venge.monotone-policy.founder"
- Delegates authority to "net.venge.monotone-policy.main" as signed by
Graydon or Nathaniel
"net.venge.monotone.experimental.policy-branches.examples.monotone-policy.main"
- should really be called "net.venge.monotone-policy.main"
- has a big list of keys which are allowed to commit to any Monotone
branch. I got this list by running "mtn automate keys" over my local
Monotone database.
The file format is designed to be extensible, to minimize the need for
backward incompatible changes. I'll go through an example now.
* ./README
Each policy can contain a human-readable README file.
* ./version_1
The rest of the policy lives under this directory. This gives us the
freedom to add new names at the top level without worrying about collisions
* ./version_1/monotone
This is a policy. The name is arbitrary - you can call a policy
anything you like, the system ignores it. A policy branch can contain
more than one policy
* ./version_1/monotone/branches
A directory that lists the branch names the policy refers to
* ./version_1/monotone/branches/net.venge.monotone
As far as I know a branch name can contain any character, so rather than
using a filename to reference them we use the contents of a file. For
clarity this file has the same name as content, but you can call the
file anything, the system doesn't care. If you want to reference two
branches, create two files.
* ./version_1/monotone/branch_prefixes
This is similar to branches, but it states that the policy applies to
all branches that have a particular prefix. No branch_prefix in a
policy may be a prefix of any branch_prefix or branch anywhere else in
that policy branch.
* ./version_1/monotone/branch_prefixes/net.venge.monotone.
Again, it is the contents of the file that specify the prefix rather
than the name. Note that this policy does not apply to, for example,
net.venge.monotone-viz. Because net.venge.monotone-viz is a prefix of
net.venge.monotone, we have to support both naming explicit branches and
naming prefixes, and we have to let the same policy apply to both.
* ./version_1/monotone/defer_to
States which policy branch this policy defers all decisions to. This
must be a branch for which policy is specified elsewhere in the policy
branch, as in the examples.
defer_to is present in, for example, the founder branch. In the main
branch we have something different:
* version_1/monotone/head
sets direct conditions that revisions must meet in order to be
considered part of the "head" of monotone. The idea is that we can
later add, for example, conditions on the ancestry.
* version_1/monotone/head/any_of
In order to be considered part of the head, it must be signed by any of
the keys in this directory
* version_1/monotone/head/any_of/475b5e52f544b996f657c143b897287b87b61978
The file contains a key fingerprint. Again, the name of the file is
arbitrary; for convenience it has the same name as content.
ACLs: I imagine that for a first pass, the user will simply specify the
name and keys for their personal policy branch in their .monotonerc.
Again, we can think about greater sophistication later.
This is all of course highly provisional. It's only a proposal.
However, hopefully a fully-worked proposal on how we can move things
forward will help.
--
__
\/ o\ Paul Crowley, address@hidden
/\__/ http://www.ciphergoth.org/
- [Monotone-devel] Policy branches - first steps,
Paul Crowley <=
- Re: [Monotone-devel] Policy branches - first steps, Paul Crowley, 2007/02/20
- Re: [Monotone-devel] Policy branches - first steps, Timothy Brownawell, 2007/02/25
- Re: [Monotone-devel] Policy branches - first steps, Paul Crowley, 2007/02/26
- [Monotone-devel] Re: Policy branches - first steps, Steven E. Harris, 2007/02/26
- [Monotone-devel] Crypto and SHA-1, was Policy branches - first steps, Paul Crowley, 2007/02/26
- [Monotone-devel] Re: Crypto and SHA-1, was Policy branches - first steps, Lapo Luchini, 2007/02/27
- Re: [Monotone-devel] Re: Crypto and SHA-1, was Policy branches - first steps, Paul Crowley, 2007/02/27
- Re: [Monotone-devel] Re: Policy branches - first steps, Justin Patrin, 2007/02/26
- Re: [Monotone-devel] Re: Policy branches - first steps, Jack Lloyd, 2007/02/26
- Re: [Monotone-devel] Re: Policy branches - first steps, Justin Patrin, 2007/02/26