Re: [Monotone-devel] Future of monotone

[hendrik]

On Mon, Jan 28, 2008 at 08:19:03PM -0600, Timothy Brownawell wrote:
> 
> 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.
> 

There's the libssl package in Debian.  aptitude tells me

Description: SSL shared libraries
  libssl and libcrypto shared libraries needed by programs like 
apache-ssl, telnet and openssh

  It is part of the OpenSSL implementation of SSL.

Is that at all relevant?

-- hendrik