Re: [Monotone-devel] Re: Re: Re: How will policy branches work?

[Timothy Brownawell]

On Wed, 2008-02-06 at 17:29 +0200, Boris wrote:
> On Wed, 06 Feb 2008 15:27:22 +0200, Timothy Brownawell  
> <address@hidden> wrote:
> 
> > On Wed, 2008-02-06 at 12:30 +0200, Boris wrote:
> >> On Tue, 05 Feb 2008 19:30:28 +0200, Zack Weinberg <address@hidden>  
> >> wrote:
> >>
> >> > [...]Because this is a distributed VCS, we can't, ultimately, prevent
> >> > people from doing whatever they want to their own copy of the
> >>
> >> It might be possible if policy settings and the list of administrators  
> >> are
> >> stored in the database. Even if you have a copy of the database the
> >> database knows who the admininistrators are and will prevent others from
> >> changing the policy settings.
> >
> > No, it's not possible. The closest you can get would be to compile in
> > your own get_projects or get_revision_cert_trust hook that looks at some
> > network share or compiled-in data that you don't tell people about, but
> > even then they'd just have to download a non-patched monotone and maybe
> > come up with their own project definition files.
> 
> You are talking about the policy branches as they will be implemented for  
> monotone? I was talking about distributed VCS in general, and with  
> private/public keys I don't see why it should be utterly impossible to  
> support centralized permission settings in a distributed VCS (they would  
> need to be encrypted with the adminstrator's private key, and the public  
> key of the administrator would need to be embedded into the database).

You can't prevent people from getting/giving access without a completely
locked-down environment.

You can prevent them from *accidentally* getting/giving access at sync
time (can't get the code on to your machine) and checkout time (can't
get the code out of your repository). Sync-time prevention can be on
either server or client side, but in a distributed system has to be on
both to be effective. If you have sync-time checks on both sides, you
can only get access to things with help from someone who already has
them on their machine.

get_revision_cert_trust() is monotone's current hook for preventing you
from accidentally checking out things you don't want to.

get_projects() is in my policy branch implementation, and governs how
you can name branches. If a branch isn't named, you can't check it out.
You also can't ask for it by name, but this isn't very helpful since you
can just ask for everything.

It is possible that policy branches will end up providing
'read-permissions'-like functionality, which is a server-side mechanism
to prevent accidental access at sync time.

It is remotely possible that this (or our current 'read-permissions'
handling) could be extended to be a client-side mechanism, where you can
by default only push things that the server has permission to read.


-- 
Timothy

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