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 :-). _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
