[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Future of monotone
From: |
hendrik |
Subject: |
Re: [Monotone-devel] Future of monotone |
Date: |
Mon, 28 Jan 2008 22:15:45 -0500 |
User-agent: |
Mutt/1.5.9i |
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
Re: [Monotone-devel] Future of monotone, Ethan Blanton, 2008/01/28
Re: [Monotone-devel] Future of monotone, Jack Lloyd, 2008/01/28
[Monotone-devel] Re: Future of monotone, Boris, 2008/01/31