Re: [Monotone-devel] encrypted monotone (and digression on
On Mon, Jul 10, 2006 at 12:21:46PM -0700, Nathaniel Smith wrote: Well, umm, blame cmarcelo, I guess :-): http://del.icio.us/tag/monotone Ah, right. That's Caio. As a practical matter, I find it unlikely that the FSF will release a GPL v3 that somehow cannot be applied to, say... gnupg. Consult a lawyer etc. etc., but personally I'd just slap v2 or later on it and worry about v3... later. Like, after it actually exists :-). I think you're right. I'm a bit of a paranoid when it comes to legal issues, but OK -- GPL v2 it is! (In the mean time, a number of people, myself included, will not want to look at any non-free code, regardless of author's expressed plans.) I never had the intention to make it non-free. It's just that I wasn't OK with that problem (in particular, since the system could be used to encrypt source code, this could be a problem -- but I'll just use teh GPL anyway) Ah, makes sense -- so it is push/pull only? What do you do to allow incremental pull? (Or do you? And if not, how does it differ from gpg --encrypt foo.mtn? ;-)) Actually, it converts your ordinary database to an encrypted one (so you keep both on your desktop/laptop/whatever). When you synchronize, you use the encrypted database. In untrusted hosts you can keep only the encrypted one (the keys won't ever get there, since they're not necessary for syncing). Since the packets are individual files in the encrypted database, when they are synced only the relevant ones are transmitted. I'll work more on that page and on packaging the code later. Right now the site is probably not up to date with the work, and I'm not sure if the mtn server is working there. (Have to work a lot on another project now, can't stop!) J. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] encrypted monotone (and digression on
On Sun, Jul 09, 2006 at 12:10:42PM -0700, Nathaniel Smith wrote: Just noticed this project: http://aleph0.info/apso/ Early stages, but might interest some people here. Er... That page is terribly outdated. The project has gone through many changes after I set up the page. And I'm curious to know how you got that link, since I only told 5 guys about it. :-) I will try to update it later, but I am really busy these days, so I'm not sure when I'll be able to do that. Currently proprietary licensed, though the webpage claims that will change. I am trying to understand the implications of sayin GPL v2 or a later version. GPL v3 seems to have problems with cryptography (and in particular, that project can be used to hide source code, which is something RMS would not like, I guess) If it's released as v2 or later, then someone writes a plugin and releass it under v3, and well, I'm not sure that would be good. I haven't looked at their technique yet; my plan to do something like this was to just teach mtn-dumb how to wrap encryption around each of its packets, and HMAC its merkle keys. The advantage is that mtn-dumb is transport only; you can't get nearly so much encryption if you have to be able to do fancy VCS operations like finding heads, where you need indexing, etc. So it's actually a good thing in an encrypted store if the only things it supports are push and pull. What I did was to encrypt packets and store them in another database. For other VC systems, I plan to encrypt deltas and any meta-information necessary to rebuild the database. (I've been thinking about encrypted storage because I've been getting increasingly frustrated at moving files around by hand between desktop/laptop/school, and thinking how to write a runs-in-background, I-don't-have-to-think-about-it, promiscuously-communicating eager file transmitter, and the obvious solution is to use some simple wrappers around monotone. But then you want to be able to use an untrusted host as a rendezvous point. Exactly! :-) J. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] encrypted monotone (and digression on
On Mon, 2006-07-10 at 13:29 -0700, Rob Schoening wrote: but my question is really: how vulnerable is mtn serve today to DoS and buffer overrun type exploits? DoS: It'd be fairly simple to make monotone eat all your CPU (or on an SMP box, as much CPU as a single-threaded program can eat). If you give someone write access, they can also fill up your disk. Buffer overrun: We tend to not use fixed-size buffers, so I don't think this is terribly likely. Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
