Re: [Monotone-devel] Re: [RFC] versioned policy -- introduction

[Timothy Brownawell]

On Sun, 2006-09-10 at 08:44 +0200, Wim Oudshoorn wrote:
> Timothy  Brownawell <address@hidden> writes:
> >> SCENARIO III: A project leader leaves
> >> -------------------------------------
> >> 
> >> Expected behaviour:
> >>          The new or remaining project leader can revoke
> >>          the 'commit' rights to the FOO.Stable branch.  However
> >>          all certificates handed out by the ex-project leader up to
> >>          the date he left are still considered valid.
> >> 
> >> 
> >> Problems:
> >>         
> >>         Suppose we have in FOO.Stable the following
> >>         
> >>         history:  Rev A (VERSION=0.1, signed by: ex-leader, 
> >>                    |     at that time project leader)
> >>                    |
> >>                   Rev B 
> >> 
> >>         Now the the project leader leaves and we want 
> >>         to keep valid the signed Rev A, but not any later revs.
> >> 
> >>         Because we can't trust the date certificates it is no use
> >>         adding a date to the revoke.
> >> 
> >>         Suppose now the ex-leader does the following:
> >> 
> >>                 Rev A (VERSION=0.1)
> >>                    |  \
> >>                 Rev B  \ 
> >>                        Rev C (VERSION=0.2, signed by now ex-project leader)
> >> 
> >>         and synchronizes with our database.
> >> 
> >>         If a user does monotone co -r c:VERSION=0.2, what happens?
> >
> > The control branch has multiple conflicting heads, which is an error
> > condition. Either the heads will have to be merged, or the users will
> > have to explicitly choose which one to use.
> 
> What do you mean exactly with the 'control branch' has multiple heads?

It looks like I mean that I misread what you wrote.

What would happen is either (1) that the revoke should include a
frontier (in this case, containing only B), behind which certs from the
revoked key are OK, or (2) it should have a list of certs from that key
which are still to be trusted. (1) would be much smaller, but only works
for branch certs. Or after the revoke, someone has to re-issue all certs
by the revoked key.

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