monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] newbie question - SHA1 vs serials


From: Richard Levitte - VMS Whacker
Subject: Re: [Monotone-devel] newbie question - SHA1 vs serials
Date: Wed, 20 Apr 2005 03:52:18 +0200 (CEST)

In message <address@hidden> on Tue, 19 Apr 2005 12:39:41 -0700, "K. Richard 
Pixley" <address@hidden> said:

rich> Richard Levitte - VMS Whacker wrote:
rich> 
rich> >In message <address@hidden> on Tue, 19 Apr 2005 09:50:57 -0700, "K. 
Richard Pixley" <address@hidden> said:
rich> >
rich> >rich> As I read the manual, (the sum of my monotone
rich> >rich> experience), monotone is currently vulnerable to these
rich> >rich> problems already.  And finding a means of addressing it
rich> >rich> would seem to be a welcome addition in any case.
rich> >
rich> >I'm curious.  Do you mind diving into this part?
rich> >
rich> Situation A:  Intellectual property.  My company has a policy
rich> wherein all work must be done on company machines on company
rich> sites.  I want to allow public key access within the company,
rich> but none others.  Note that company does have remote sites.  As
rich> sits, I can't use monotone to accept company changes while
rich> rejecting changes those same users might attempt to make from
rich> home.  I can do this with firewalls and such, if I have access
rich> to them, but not with monotone.

This sounds very much like a packet filtering problem.  I'd say that's
outside of monotone's scope.  And if you're very worried about IP
leakage, don't give your developers laptops, pure and simple.  It's
either that or you will have to trust their behavior around having a
laptop.

rich> Situation B:  Compromised keys.  If you jack my laptop, my
rich> company is hosed.  We need a more interactive authentication
rich> mechanism to resolve this problem, I think.

If someone jacks your laptop (I won't :-)), you would probably worry
more about the database that's there and contains the complete content
of your IP.  The keys are only compromised if you protected them with
a lame pass phrase and they get cracked.  Comparatively, I'd regard
that as a lesser problem than the exposed database.

rich> Situation C:  I'm part of a Big Company and Big Company has
rich> significant investments in ldap already.  We're not willing to
rich> implement another project wherein we educate all 10 million of
rich> our employees in public/private key encryption, assign and
rich> distribute the keys to all 10 million+ repositories.  Instead,
rich> we want to leverage our existing authentication mechanisms.  And
rich> since we're a closed system, we can do that fairly simply,
rich> provided that we can authenticate the machines involved, (tls,
rich> kerberos, or whatever).

This sounds like the beginning of a complete redesign of the monotone
authentication mechanism.  I assume there's space for user
authentication and signatures in your system.

rich> I think there are some others, like flooding problems, but I
rich> don't yet understand how revisions propogate well enough to name
rich> them.

They propagate through a protocol that's very similar to rsync.
Basically, it only transfers the information that's missing on the
other end.

rich> Eg, if my respository accepts changes from Bob & Carol, I sync
rich> to you, but your repository only accepts changes from Bob, not
rich> Carol, then what happens to Carol's changes?  What happens when
rich> Bob's latest change is a revision of one of Carol's?

Hmm, I haven't experimented with that so much, so I really don't
know.  You do trigger my curiosity, so I might run a test to see what
happens.

rich> I do have concerns about the multiheaded model.  I can see how
rich> it can work for small projects.  But at some scale, perhaps 128
rich> heads?

My choice would be to see if there's a need for named branches in such
a situation.  I honestly believe the developers will be able to take
it upon themselves to merge a little now and then, especially if they
notice that they aren't getting some changes because they're hanging
on to their own head, or because monotone tells them there are several
hreads to choose from.

rich> Or a scale where the heads query never returns the same answer
rich> twice in a row?  I'm not sure it will actually be manageable.

Same answer.  I yeah, I agree, with a huge number of heads, management
may be tough.  How many developers building on the same source are we
talking about?

rich> I suspect that at some scale, there will need to be some other
rich> form of user partitioning or phased or heirarchical revision
rich> propogation in order to track all of the changes and forks.
rich> It's not yet clear to me how this will work out or even at what
rich> point it will break down.

Those are good points, and worth investigating if we get a chance.

>From where I stand, the biggest scalability problem may actually be
the size of the database itself, for huge installations...

rich> >rich> Monotone does have some very nice architectural features,
rich> >rich> though, especially when compared with other current free
rich> >rich> software offerings.
rich> >
rich> >It would actually be nice to hear what you like about monotone (I'm
rich> >writing notes for a lecture on monotone, so I want to hear things like
rich> >this.  Really, this whole discussion has been a lot of food for
rich> >thought so far).
rich> >  
rich> >
rich> See last paragraph.
rich> 
rich>     * automatic forks in the repository
rich>     * the potential for revision propogation in the background,
rich>       unattended
rich>     * the ability to separate syncing from merging
rich>     * a decentralized user based authentication mechanism, (this
rich>       is a dual edged sword, though, it doesn't scale and it
rich>       doesn't lend itself to centralized control).
rich>     * generalized database for associating metadata with
rich>       revisions

Noted.

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis




reply via email to

[Prev in Thread] Current Thread [Next in Thread]