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

[Bruce Stephens]

"Nathaniel J. Smith" <address@hidden> writes:

[...]

> Example 7:
>
> ...so 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.

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

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?

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

[...]