[Monotone-devel] Re: read/write permissions

[Boris]

On Fri, 26 Jan 2007 22:16:37 +0200, Graydon Hoare <address@hidden>  
wrote:

> Boris wrote:
> > What happens if a user who has only read-permission for branch A writes  
> > something to branch B? As far as I see this is possible as  
> > write-permissions are per database and not per branch. If branch B is  
> > only for privileged users is it still protected? I'd say so as the new  
> > user can't link his certificate into existing revisions in branch B. Is  
> > this correct? But does everyone with read-permission to branch B see  
> > now two heads?
>
> I believe at the moment that any database set up to reject the user  
> writing to branch B will reject certificates from that user that bind a  
> revision to B, and possibly reject the revision as well.
>
> Still, it's possible for the revision and/or cert to be transmitted by  
> some other means. Using read or write permissions to control trust is  
> the wrong thing to do; permissions are really just coarse measures to  
> control visibility and abuse. The point of modeling commits with certs  
> is that users at the ends of the system can decide what to trust  
> themselves, independent of the trustworthiness of intermediaries in the  
> transmission path.
>
> (We're hoping to put together a simpler and more useful bootstrapping  
> trust system eventually. For the time being, users must define their own  
> trust rules with lua hooks)

The reason I ask is that branch B contains source code and branch A tests.  
A tester should be able to read/write branch A but not branch B. I can  
restrict read-access but can't avoid that a tester writes to branch B. As  
far as I understand I need to change get_revision_cert_trust() to make  
sure that no code from a tester ends up in my workspace and in the release  
version of the product.

Your argument that certs can be transmitted differently makes sense. But  
then I wonder if my approach is wrong: Using different branches in the  
same database for different projects doesn't seem to make much sense if  
you want to restrict read/write access per project. I would need to put  
one project in one database to do this (which would complicate matters  
however if you have a central server you'd like everyone in the team to  
synchronize with - no matter what project they work on).

Any ideas how to organize this?

Boris