Re: [Monotone-devel] encrypted monotone (and digression on

[Rob Schoening]

I have a somewhat unrelated question that touches on a more fundamental security issue:

 

what is the relative security risk of running netsync on a public port assuming it's running as a non privileged user?  how much of a vulnerability is it for the host that's serving it?

 

it is, of course, relatively simple today to deploy mtn on a private port and use SSH port forwarding to access it which all but eliminates this problem. Or, eventually, one could use "mtn dumb" over SSH.

 

but my question is really: how vulnerable is "mtn serve" today to DoS and buffer overrun type exploits?

RS

 

On 7/10/06, Nathaniel Smith <address@hidden> wrote:

On Mon, Jul 10, 2006 at 08:18:27AM -0300, Jeronimo Pellegrini wrote:
> 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.  :-)

Well, umm, blame cmarcelo, I guess :-):
http://del.icio.us/tag/monotone

> 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.

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
:-).

(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 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.

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? ;-))

-- Nathaniel

--
"On arrival in my ward I was immediately served with lunch. `This is
what you ordered yesterday.' I pointed out that I had just arrived,
only to be told: `This is what your bed ordered.'"
-- Letter to the Editor, The Times, September 2000


_______________________________________________
Monotone-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel