Reported by Unknown User, Jun 9, 2006
(This entry was imported from the savannah tracker, original location: https://savannah.nongnu.org/bugs/index.php?16790) The one feature of OpenCM that I really miss in Monotone is the support for SSL communication (actually OpenCM always ran over SSL, but that isn't really relevent). Privacy is important for me (I have some things in Monotone I wouldn't want other people to see, such as proprietary code and my personal configs, and I often work from coffeeshops, etc). Also the fact that Monotone has a custom authentication protocol somewhat frightens me. I know you guys are smart, and I've looked at it and didn't see any problems, but this really does seem to be something where standard == good, because standard protocols are the only thing that the real security people spend a lot of time looking hard at, and at this point Monotone isn't popular enough to attract serious attention from that sphere. Taking into account the obvious responses: - It would require yet another dependency. I agree that isn't great. It would boil down to either switching from Botan to OpenSSL, or using Ajisai. Neither seems like a compelling choice. - Someone has to do the work, and it should be me since I want this. Yeah, I know. I'm busy, as I'm sure you are. :/ - Stunnel / SSH tunneling: My feeling on this is the same as --daemonize; this is something which should just work. Stunnel is IMO a stopgap at best. If it is something that can be done automatically without extra work from the user, it should be done. - Certificates are a mess. Obviously. However using self-signed certs with manual imports is basically the same thing the current raw key system, but provides an easy (standard, documented, already supported) way of binding metadata to the key (maybe it is just me, but having the email address be the index for a key seems like a bad idea - what if I want to have multiple keys? What if I lose my key? I haven't seen a good way of handling these cases...). And it does leave open interesting opportunities WRT project-specific CAs, key revocation, etc in the future, if someone wants to deal with that complexity later on. I suppose there are two questions here, one is if it is a good idea (in principle) to use SSL+certs, another is who is actually going to do it. I don't have a good answer for the latter, but I think I can make a good case for the former. I'd be happy to discuss here or on the list if anyone wants to talk about it. monotone version: ----------------- monotone 0.26 (base revision: 4342565107f26ceda955b66c66b5b7ec152f314e) Running on : Linux 2.6.16-1.2111_FC4 #1 Sat May 20 19:59:40 EDT 2006 i686 C++ compiler : GNU C++ version 4.0.2 20051125 (Red Hat 4.0.2-8) C++ standard library: GNU libstdc++ version 20051125 Boost version : 1_32 Changes since base revision: unknown
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.
Comment 10 by Unknown User, Jun 19, 2006
(Finally bothered to get an account)