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 [EMAIL PROTECTED] 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 _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
