Re: [Monotone-devel] branch representation

[Timothy Brownawell]

On Wed, 2005-10-26 at 17:05 -0700, Nathaniel Smith wrote:
> It might make doing trust stuff significantly easier.  I _think_ a
> design criterion for a trust system is that I want to be able to
> specify rules for trusting certs that aren't branch certs, and I want
> to do this per-branch.  This seems very tricky, if the rule for
> deciding whether you trust a 'foo' cert begins "collect all branch
> certs on the same rev, invoke the branch trust rules on them, for
> each branch cert that turns out to be trusted, find that branch's
> trust rules for 'foo' certs, and then somehow combine the results of
> applying each branch's rules". 

If they don't all match, print a warning and exit?

>  And there are probably horrible
> convoluted attacks:
>   Alice has tag and branch cert rights to branch A.
>   Bob has tag and branch cert rights to branch B.
>   Alice wants to check out the tag 'A-release' so she can send it to
>     the CD manufacturers.
>   Bob does good work over on his project, so Alice does trust him to
>     tag revs on branch B, but he happens to hate project A.
>   Bob takes a buggy rev R on branch A, and adds two certs to it:
>     branch: B
>     tag: A-release
> Now rev R is, according to the trust rules, quite definitely in both A
> and B.  The A-release tag on it is trusted with respect to branch B's
> rules, but not respected with respect to branch A's rules.  So... do
> we trust the A-release tag, or what?  I guess the unavoidable
> conclusion is that you can't determine cert trust based on just the
> contents of the DB plus the current trust rules, but also need to know
> something about the current context?  (checkout -b B -r t:A-release
> should work, checkout -b A -r t:A-release should silently ignore it?)
> This seems bad.  Maybe I'm missing something.

Perhaps this is a reason to keep different projects in different
databases? Bob could just put the A-release tag on something that's
*only* on his branch, and it'd work just as well.

> (Okay, maybe trust issues _have_ been stewing around in the back of my
> head for more than 3 months.  But I don't really understand them, so
> it's maybe premature to use them as arguments in a discussion...)
> 
> This idea does add a significant new piece to the model -- instead of
> the nice clean DAG of snapshots _here_, and generic metadata mechanism
> _there_ setup, we have a piece of magic metadata, that needs to be
> handled differently, etc.
> 
> Umm.  Probably lots of other things to say, too, but I'll stop here
> for now :-).