Comment 1 by Unknown User, Jun 9, 2006

0.27 can speak over ssh, with an ssh:// URI form as the 
"host" parameter of push/pull/sync. It is also extensible 
in lua scripts to use any other full duplex channel you can run as a 
subprocess. Good enough?

Comment 2 by Unknown User, Jun 9, 2006

I should say "the soon-to-be-released 0.27", since there's 
no such release yet.

Comment 3 by Unknown User, Jun 9, 2006

Hrm. In general SSH is going to require that every user have an 
account on the machine, so I would say it addresses my initial 
problem while introducing one that I like even less. On the other 
hand the hooking mechanism may mean I can do this myself with some 
Lua glue and a little bit of C. I presume it is possible to allow 
anonymous pulls over netsync but require all pushes (and pulls from 
branches that have access controls) to happen over an alternate 
channel ie SSL? Also is there a way to short circuit Monotone's 
built in authentication mechanisms and so forth? I suppose I should 
go read the source now.

I can't say I'm really enthusiastic about it as a solution, but then 
again I'm not about to hack all of the nice stuff in Monotone into 
OpenCM, either, so I should probably just shut up and eat my damn 
lemons.

That does leave the key metadata thing unresolved, though. The docs 
make it sound like once a key is in the database with a particular 
email, it's impossible to introduce another key with the same email 
address. Am I wrong about this?

Comment 4 by Unknown User, Jun 9, 2006

(I have a feeling my first questions can be answered by reading the 
hook documentation. I will do so tonight)

Comment 5 by Unknown User, Jun 9, 2006

Yeah, SSH is mostly for private use. You can scale it up a *bit* if 
you put entries in your .ssh/authorized_keys file with a command 
restriction (similar to 
http://www.selenic.com/mercurial/wiki/index.cgi/SharedSSH) but it's 
not terribly satisfying, I'll admit.

The authentication layer of monotone is not terribly rich, and may 
need some further adjustment as time passes. Currently it calls 
hooks to confirm read/write accesses from the network, but it 
doesn't mention whether those accesses came over SSL (since it has 
no idea about SSL). Some extension could be possible there, 
certainly.

Key metadata has been pretty bad since the get-go. We're going to be 
having a go at cleaning this up when we do our "policy 
branch" work. This will involve storing some versionned policy 
settings in the database which describe human-to-machine identifier 
mappings, so you'll be able to rename and expire keys and branches, 
etc. That work hasn't really gotten underway yet though.

Comment 6 by Unknown User, Jun 9, 2006

Sounds reasonable. I have yet to really dig into the code (though, 
BTW, from what I've seen it is excellent work, certainly better than 
my own C++), but maybe this is a good time to do so.

Comment 7 by Unknown User, Jun 11, 2006

In principle I think we'd be happy to use SSL at the channel layer.  
Having our own crypto there gives me the heebie-jeebies, too.  There 
are some reasons why this isn't what we did from the start, though:
  * OpenSSL is GPL-incompatible, so we can't use it.  (We could in 
principle relicense monotone to add an exception, but then _we_ 
would be GPL-incompatible.  Since we currently distribute some GPLed 
and LGPLed code from third parties, and might want to do so in the 
future, and our code has itself been used in other projects, this 
option is unappealing.)  GnuTLS and Ajisai are both options.  The 
Ajisai faq says that it is still very alpha, though it's otherwise 
appealing (minimal new dependencies, presumably sane API, author has 
been responsive to our needs in the past).
  * Async sockets + SSL is a major pain in the butt.  It requires 
lots of magic, and last I checked there was no freely available 
documentation describing how to do it.
  * Most SSL code assumes you want to join in the X.509 mess -- 
e.g., you should have a key in that format sitting in a file, and 
you want to use signature chains to validate the other side, and so 
on.  It is probably possible to build an actually usable system out 
of these primitives -- i.e., one that doesn't add extra key 
distribution hassles or CAs, but still provides MITM protection -- 
but I couldn't figure out how to do it.

So, yeah.  SSL would be nice, there are just annoying practical 
issues to overcome.

(Who are you, by the way? :-))

Comment 8 by Unknown User, Jun 11, 2006

Oh, and re: the bug title -- you have to use the same system for 
both confidentiality and authentication, because otherwise your 
confidentiality is open to MITM attacks.

(Perhaps this is not that big a worry compared to having no 
confidentiality at all, but one might as well get these things 
right.)

Comment 9 by Unknown User, Jun 19, 2006

Yes, you are certainly right about async sockets + SSL being a pain. 
I know OpenSSL has had in the past (and may still have) various very 
weird failure cases when running on async sockets, and oh-my-god are 
they painful to track down. Right now Ajisai doesn't support async 
sockets at all, not to mention a distinct lack of Windows socket 
support, etc - it *works*, but I would not suggest using it in 
anything approaching production software in its current state. I 
really should start working on it again, there has been a lot of 
interest from different quarters (KDE, especially) but I'm always 
either short on time or motivation.

I think I mentioned something about MITM very briefly at one point - 
the easiest (rather, simplest) way to deal with MITM in this context 
is to simply predistribute all the certs and avoid certificates 
chains/authorities entirely. Since this is exactly the current 
model, there is no real loss in usability. (Or shouldn't, at least). 
There is some extra stuff in a self-signed cert that isn't in the 
Monotone key format (a signature on itself and some places to put 
various pieces of metadata), but you could treat such a cert exactly 
like an email/key pair if you wanted.