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
RS
On 7/10/06, Nathaniel Smith <[EMAIL PROTECTED]> 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
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel