Re: [Monotone-devel] [RFC] Monotone NETSYNC Hook Extension & Abstraction Layer

[Nathaniel Smith]

On Sun, Sep 23, 2007 at 08:02:46PM +0200, Ralf S. Engelschall wrote:
> On my road of trying to adopt Monotone for use in my various larger
> Open Source projects like OSSP, OpenPKG, etc I've last week worked on
> an important issue (at least for me) which perhaps looks strange to the
> "maximum distribution is everything which matters" guys in the VCS camp:
> 
>    How to best combine the developer-requested distributed VCS nature
>    of Monotone with the central ACL nature required at the "master"
>    repository of those projects?
> 
> To get you an impression how "deep" the problem is we try to solve
> here: we want that the developers can use full distributed VCS outside
> the central repository. Nevertheless, they have to fulfill a mandatory
> contributor agreement (to protect the licensing, etc) which especially
> means they are allowed to propagate/merge/pluck only revisions within
> a particular branch tree (e.g. "openpkg.*") and inside this tree only
> developers who have signed the contributor agreement are allowed
> to commit their stuff. As long as a developer is fulfilling these
> constraints he will be able to share his revisions (which indirectly
> usually carry the revisions of others due to merging) with the master
> repository (from which official release tarballs and packages are
> rolled). If he breaks out of these constraints, he is _forced_ to stay
> out at all.
> 
> Please do not confuse this with the idea of policy branches some of
> you already discussed. My understanding is that policy branches are
> about distributed policy _recommendations_, while I'm talking about
> central policy _enforcement_ here. So, this stuff is the other side
> of the "policy branches" medal. For a final solution one might wish
> both AFAIK. The "policy branches" are for the distribution, while our
> solution is for the "master" repository which usually is the middle of
> our proposed partial star topology.

I think this is somewhat of a misunderstanding -- in some sense policy
branches are indeed only "recommendations", because I have no way to
enforce what you do on your computer (short of crazy TCPA-like
things).  So I write down what policy I think we should all use, and
then each contributor decides whether or not they will use that
policy on their own computer.  In practice, though, if everyone else
is using that same policy, it's pretty useless to you to ignore it --
you can violate it in the privacy of your own server, but if you try
to push those revisions to anyone else they'll either never receive
them, or if they do then they'll silently ignore them anyway.
Technically, then, "enforcement" comes from the other users of the
project, but for most purposes we can just say that policy branches
are enforced.  I *think* policy branches are indeed trying to solve
the same problem you are, just without making communication-time the
one-and-only-chance to enforce security policies.

That said, that's a hard (partially unsolved) problem, so if you need
this stuff now, then it doesn't matter if policy branches can slice
bread and do your dishes, they won't be ready in the immediate future
and you might well want to keep on as you are :-).

> My partner Thomas Lotterer and I came up with the idea to solve the
> problem at the server-side of the master repository by directly
> enforcing the access control on keys, revisions, and certs during
> NETSYNC and even _ROLLING BACK_ the _WHOLE_ NETSYNC transaction in
> case an ACL fails. And I've now also developed an experimental
> implementation for this and I have written a little bit more about this
> stuff in my BLOG a few days ago (see the following URL for details:
> http://trainofthoughts.org/blog/2007/09/16/distributed-vcs-central-acl/).
> We are currently testing this stuff in practice with a few test
> repositories. Looks promising so far.

You're going to have a problem with the transaction handling here --
the server does not and can not wrap a client connection into a single
transaction.  The problem is that the server is multiplexing across
multiple connections at once, but with sqlite (and RDBMSes generally,
to some extent) there is no way to have multiple parallel transactions
open at the same time, to keep separate the data that's arriving in
parallel from multiple clients.  So the server commits regularly.

> Now comes the time where I would like to let you Monotone hackers review
> this stuff in more detail. The stuff mainly looks like this (see the
> attachments to this mail for a snapshot of this code):
[...]

Looks interesting, but no time to take a closer look right now.

> PS: If you think I like Lua just because I coded all this stuff in Lua,
>     please see http://trainofthoughts.org/blog/2007/09/16/lua-popularity/
>     and give your feedback there, too ;-)

Yes, the reason Lua is popular has nothing whatsoever to do with the
language itself, and everything to do with the fact that the
interpreter was designed from the ground up to be built into a larger
C program.  So it's one of the only languages around that gets the C
binding and free-standing parts right.  (E.g. the Python-C API is not
too bad, but just try building a usable python interpreter into a
single executable with no library dependencies.)

Javascript *should* do well here, but there aren't any implementations
with even a shred of decent documentation.  So Mozilla people use
Javascript when they need a little embedded language but no-one else
does.

I don't know Arena or Nasal.  I do note that Nasal released version
1.0 in 2006, while Lua released version 1.0 in 1993... I think there
is a little difference both in maturity and simple time for people to
notice its existence and build a community around it.

-- Nathaniel

-- 
"But suppose I am not willing to claim that.  For in fact pianos
are heavy, and very few persons can carry a piano all by themselves."