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

[Timothy Brownawell]

On Sat, 2007-01-20 at 03:15 -0800, Nathaniel J. Smith wrote:
[snip snip snip] 
> Example 3:
> 
>      +ab
>      /  \
>   -b/    \-a
>    /      \
>   a1       b1
>   
> Here we have some sort of determined disagreement between admins.
> There isn't much monotone can do except point out the problem, and let
> the people involved work it out.  There are basically two options:
> wedge everything until people work things out (possibly by all users
> deciding to update their trust seed to follow whichever admin is
> actually trustworthy), or drop back to the last thing that everyone
> can agree on (i.e., actually kill off _both_ a1 and b1, and go back to
> the trust seed, in this case, for now).

You must E() on this, or it becomes impossible to properly kick out an
admin.

Say b turns evil, resulting in a1 being committed. At any time after
this, b can commit b1. If this causes a fallback to the original trust
revision, then b has just re-granted itself its admin privileges. Even
if you W(), automated scripts/buildbots probably won't notice anything.

If this causes an E(), then everyone must update their trust seed. Which
is annoying, but won't fail silently like a fallback with a W() that
nobody sees would.

> Example 4:
> 
>      +abc
>       / \
>      /   \-c
>     /     \
>    c1      b1
>    |
>    a1
> 
> Here, c1 is clearly not trusted wrt b1.  This means that a1 is also
> not trusted wrt b1.  Not entirely sure what this should do -- like a
> may have simply committed that revision without knowing that c was
> (about to become) illegitimate, but gets caught in the crossfire
> between b and c?  Maybe issue a warning?

This also needs to E(), at least some of the time. Otherwise, anyone who
can revoke c's access can also undo any changes committed as a
descendant of one of c's revisions. Even if those changes aren't in an
area that they should be allowed to change.

Say, b is initially allowed full access to foo/ and bar/ in the source
tree, and is allowed to grant/revoke access to bar/, and to decide who
else can grant/revoke access to bar/ . Say c1 contains changes to who
can access bar/, and a1 revokes b's access to foo/ . b can commit b1,
which denies c permission to grant/revoke access to bar/, making c1
invalid. This also erases a1, and gives back b's access to foo/ .


                 (Initial)
      <everything>              + Admin
      /foo                      + Bob
      /bar                      + Bob
      grant/revoke /bar         + Bob, Carol
      revoke grant/revoke /bar  + Bob

               /          \
              /            \

     /bar  + Greg         grant/revoke /bar  - Carol
          /                   \
     revision c1 (Carol)    revision b1 (Bob)
         |
         |
     /foo  - Bob
         |
      revision a1 (Admin)


------------------------------------

Idea: In order for a head to invalidate another head, whoever committed
the change that makes it invalidate the other head must have sufficient
permissions to be able to make the inverse changes to what the
invalidated revisions did.

Idea: Require DaggyFixes-style history structure for the policy
branches, and leave unrelated heads unmerged. Policy branches would then
be much shallower and wider than a similar-sized source branch, and
would genrally have many heads.

Idea: When there are multiple heads that don't trust eachother, W() and
proceed using a virtual merge({heads}) revision, but with the merge
operator for this case being "and" instead of deterministic *-merge. 


-- 
Timothy

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