Re: [Monotone-devel] Re: Monotone Security

[William Uther]

On 20/10/2008, at 1:36 PM, Brian May wrote:

> William Uther wrote:
> > Now let's imagine that Bob merges all heads in his database, but  
> > without fully checking Charlie's change.  At this point, Bob signs  
> > the newly merged revision.
> This is where you need a distributed system for sending trust data  
> (as discussed here as "policy branches"), so if Alice doesn't trust  
> Charlie, Bob won't trust Charlie either.

That sort of "web of trust" might not be a bad thing, but I'm not sure  
it helps here.

> Also, if Bob signs a merge, then he is essentially saying he trusts   
> both versions, IMHO (although maybe this is questionable because the  
> UI makes merges without reviewing the changes so easy). Then it  
> shouldn't matter if Alice sees the merge result.

Yes, as I noted at the bottom of my email.

Monotone signs revisions not patches.  Each revision implicitly  
includes all prior patches and when you sign a revision you sign them  
all.  (You don't sign the meta-data associated with those patches, the  
certs, but you do say you're happy with the end result of the patches  
themselves.)

This is a feature in many situations, but it is also problematic in  
some situations and I think it is an important part of understanding  
the security model of Monotone.

Let me give a hypothetical comparison example.  Imagine a modified  
DARCS that signed patches (as opposed to the way monotone signs  
revisions).  You could then imagine checking out a 'virtual revision'  
that took the head, backed out all patches not signed by someone you  
trusted, and gave you the resulting revision.  With this system,  
someone slipping in a malicious patch would not have any effect,  
because it would be automatically reverted for anyone who didn't trust  
the associated signature.  To merge in a patch from someone untrusted,  
you'd have to sign it yourself to say you trust it, or change your  
trust settings.

Be well,

Will       :-}