Re: [Monotone-devel] Future of monotone

[Timothy Brownawell]

On Mon, 2008-01-28 at 14:21 -0500, Jack Lloyd wrote:

>  - 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.

This is a policy branch thing, but will also require changes to how we
store certs. I don't expect it should require certs to be re-issued,
unless combined with some of the other cert changes being discussed.

>  - 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.

Monotone doesn't handle write permissions as "you may/may not write
this", so much as "I will/will not ignore your writing this". Policy
branches are a way to coordinate this ignoring. The ignoring is
currently about as flexible as it can get, but it's also a pain to use.

>  - 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.

I think it would be cool to find a good C++-friendly library that does
both sides of the SSH2 protocol. Besides handling
authentication/confidentiality/integrity, this would also make it easier
to have the same server provide both netsync and the automate commands
over the network. Then you could run, say, viewmtn without needing funny
tricks to deal with database locking.

Of course, I'm not sure where to *find* such a library.

-- 
Timothy

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