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

[Zack Weinberg]

On Wed, Feb 6, 2008 at 10:29 AM, Boris <address@hidden> wrote:
>  >> > [...]Because this is a distributed VCS, we can't, ultimately, prevent
>  >> > people from doing whatever they want to their own copy [...]
>  >>
>  >> 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).

Anyone with a copy of the database could substitute a different public
key for the administrator's, though.  We can make this difficult but
not impossible -- if someone is determined enough, they could binary
patch the database file.

We think that it'll be both friendlier and more secure if we allow
people to do whatever they want locally, but not force changes in
violation of policy on anyone else.  It ends up working almost like
what you describe in practice.  There is a set of permission settings
signed (not encrypted) with the administrator's private key.  One of
those settings is the administrator's public key.  Anyone can, in
their own database, substitute a permission set signed with their own
private key which lists their own public key as having administrative
rights.  But everyone else's database ignores that change because they
only trust the original administrator, not the usurper.

Am I making sense at all?  I can break out the ASCII art revision
trees if it will help.

zw