[Top][All Lists]

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

Re: [Monotone-devel] Re: Security is hard. Let's work on policy branches

From: Timothy Brownawell
Subject: Re: [Monotone-devel] Re: Security is hard. Let's work on policy branches anyway.
Date: Fri, 13 Apr 2007 06:58:52 -0500

On Thu, 2007-04-12 at 12:36 +0100, Bruce Stephens wrote:
> "Nathaniel J. Smith" <address@hidden> writes:
> [...]
> > Example 7:
> >
> > actually, you don't even need more than two heads to get
> > crazy-hairy cases.  Here's an example that involves just three
> > nodes...:
> >
> >         +abc
> >          / \
> >       -c/   \-a
> >        /     \
> >       a1      b1
> >               |
> >               |+a
> >               |
> >               c1
> >     
> > Here a1 is trusted wrt c1, but c1 is not trusted wrt a1.  So
> > presumably we should eliminate d1, leaving us with {c1, b1} as our
> > candidate head set.  However, a1 is _not_ trusted wrt b1.  So
> > presumably we should eliminate a1 as well, leaving us with just {b1}.
> > But then, maybe c1 should be trusted again...?  Or what...?
> OK, so *-merge tells you about the merged case, and now you're worried
> about unmerged heads.
> But can't you just ignore that?
> i.e., in the above case, just stick with +abc and complain to the
> user?  I guess I'm imagining some statefulness: maybe my workspace
> remembers not just its branch and revision, but also the most recent
> policy branch revision.

Probably not so good since you could get stuck on a microbranch without
doing anything. Then you miss any legit changes to the other
microbranch(es) until someone notices and merges them.

> Maybe it's OK then just to update the policy branch like an ordinary
> branch (so at b1, you'd update it to c1)?

Sure, but it'd be manual just like any other update. You say "I want to
start this policy branch with revision X" (ie, change your trust seed),
and anything not descended from that revision is ignored.

> That means I might miss the critical -c change from c1, or the
> critical -a change from b1.
> But that might happen for other reasons.  In the PKI world (presuming
> one doesn't assume OCSP or something else requiring connectivity), you
> mitigate that using times: a CRL says when I ought to get an update.
> A reasonably monotone equivalent might be to (optionally) mark a
> revision (maybe include this in the revision itself, rather than
> attached with a certificate which might get lost) with the revision of
> a policy branch.  In that case, monotone might require that I use a
> policy revision that's a descendent of the specified revision?

No. Partly because that seems fairly distinct from what a revision (in a
non-policy branch) is, and partly because there are reasons to want to
use a different trust seed than the revision's author (forking a project
or importing it as part of another come to mind).

> i.e., when something important happens requiring a policy update, you
> mark the net.venge.monotone revision accordingly, to make sure people
> get the updated policy (or at least know about it).

We have to redo netsync for this anyway. What to sync will have to be
specified in terms of projects and branches within those projects, so
just make sure that it always includes the policy branch for any
included projects (ask for nvm or, and nvm.[policy] is included
automatically). This is really the only way to go, since we want policy
branches to be transparent as much of the time as possible.


Free (experimental) public monotone hosting:

reply via email to

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