Re: [Monotone-devel] Future of monotone

[Jack Lloyd]

On Sun, Jan 27, 2008 at 02:41:37PM +0100, Thomas Keller wrote:

> So where lacks monotone the most?

I've been using Monotone for about 20 months, initially just for
Botan, and now all of my projects as well as all configs/scripts that
I keep in my home directory. Overall I've been very happy with it, it
replicates much of what I liked about OpenCM (and, like most DVCS
tools, makes using SVN at work feel like rolling boulders up a
hill). Many people have mentioned the speed (or lack thereof), and
while of course faster is always better, I have not had any major
problems (but then again my largest mtn db is only ~8 megs/800 revs).

The big issues I have with mtn that are affecting my workflow right
now are related to permissions (and security in general). It seems
like some of this falls under the policy branches umbrella, but not
all.

 - Ability to replace lost/compromised keys (without changing my email
   address). Also the ability to have multiple keys with a single
   email address seems essential to me. Why? So they can be
   selectively revoked as needed - one address@hidden key for my
   laptop, another for my desktop, etc. I am the same person in both
   cases, with the same email address, so it makes perfect sense (to
   me, at least) that revisions could have identical author fields but
   be signed with distinct keys.

   This would suggest a petname system [1] of some sort, wherein all
   revisions are signed based on a keyid rather than an email address,
   with the mapping from key->human name happening at a different
   stage. That would also allow for email changes without requiring
   key rollover. What OpenCM ended up using ([2], sec 7.2), is
   somewhat like petnames within a policy branch cert.

 - A more flexible and clear permissions model. TBH the algorithms
   Monotone uses for trust evaluation and read/write permissioning are
   quite opaque to me (which makes me very nervous about using
   Monotone in a multiuser situation). The ability to allow a user
   write access to just a particular branch is my most immediate need
   (I'd like to give people the ability to check into selected
   branches under net.randombit.botan without also letting them see or
   modify my personal configurations, commercial projects, &c, all of
   which are stored in a single mtn db on randombit.net). Currently
   the answer for this in Monotone seems to be policy branches.

 - Encryption of network traffic. In OpenCM, we ran the equivalent of
   netsync over TLS [3] (keys in OpenCM were self-signed X.509
   certificates, which were used to both mutually authenticate the
   server and client using TLS client authentication, and provided an
   easy method of binding metadata to public keys). What netsync is
   doing WRT authentication looked reasonably sane and safe to me when
   I examined it, but I don't feel much reason to be confident in
   it. And lack of confidentiality of the netsync is a showstopper in
   some environments where I would like to use mtn.

As of today, I've spent some time looking through the Monotone source,
and made a few minor modifications (none of which were ever
complete/solid enough to throw back over the wall). But a couple of
issues that have taken up a lot of my time and attention in the last
year are looking to be resolved in the next month or so, and I'm
hoping it will be possible to invest some of that in improving
Monotone. Having already used one DVCS that subsequently petered out,
I'd very much like to avoid repeating the experience. :)

So, two questions:

 - Are my wishes enumerated above unrealistic or actively undesirable?

 - If not, what branches/code/wiki pages/list threads should I start
   by reading? So I can better understand the current state of
   mainline Monotone in these areas, and see what has already been
   discussed and/or accomplished.

-Jack

[1] - http://www.skyhunter.com/marcs/petnames/IntroPetNames.html
[2] - "CPCMS: A Configuration Management System Based on Cryptographic Names"
  (http://www.opencm.org/papers/cpcms2001.pdf)
[3] - "Access and Integrity Control in a Public-Access, High-Assurance
       Configuration Management System"
  (http://www.opencm.org/papers/usenix-sec2002.pdf)