[Monotone-devel] Re: [RFC] versioned policy -- introduction

[Bruce Stephens]

Nathaniel Smith <address@hidden> writes:

[...]

>   * We need some way to manage "commit" permissions.  For now, people
>     have been faking this functionality using netsync permissions,
>     but this approach is deeply unsatisfactory.  A major design goal
>     of monotone is to make communication as noncommittal as possible;
>     to make it so you can always, painlessly and without worry, send
>     information around.  Not only that, but netsync permissions don't
>     really work right for this anyway; we have all these lovely
>     signatures and audit trail stuff, and it's completely orthogonal
>     to the netsync permission system that everyone uses in practice.
>     -- Solution?: create some kind of local, per-project ACL list,
>        which is modifiable by some users (controlled by the ACLs),
>        which everyone locally uses to decide which certs they believe
>        in.

But it's my database, so surely I get to decide which ACL list forms
my trust seed, so if I decide I want to commit, then I can make that
possible.

More than that: that's an important feature, not a bug.  I shouldn't
be prevented from committing to a tree just because its owners haven't
(currently) allowed me to.

So is there something you aren't describing, to do with how all this
gets enforced?

I can think of a couple of obvious ways: it could be done during
netsync; it could be done at update (merge, etc.) by ignoring certain
revisions (like get_revision_cert_trust).

Am I right in assuming you're intending the latter: that (as now) if
someone has netsync write permission, then they can transmit arbitrary
stuff to whatever branches they like; but the process of ignoring it
will be more automatically handled for everyone in the relevant
projects?

Also, is this one trust seed per database?  So does this force one
database per project (quite probably a good way to do things, but not
the way everyone works currently)?

[...]