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

[Richard Levitte - VMS Whacker]

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

rich> Maybe I wasn't clear enough initially.  I meant: name
rich> repositories.

Uhmm, I fail to see how the name of my repository is interesting to
anyone else but myself.  Sure, I also serve a copy on
repository.lp.se, with the usual monotone port, but that doesn't tell
you anything about the name of my repository itself, and it shouldn't
bother you what it is.

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

rich> 1) There's a loop in our delta distribution mechanism.  This
rich>    should already be covered by current logic.  If you're sent
rich>    the same delta twice, what happens?  I haven't checked, but
rich>    my guess is that we're comparing lists of available delta
rich>    id's anyway so this wouldn't happen. 
rich> 
rich> 2) If you already have a 1:foo.bar.com, you're not going to
rich>    accept another.
rich> 
rich> 3) If the incoming revision is, oh, say, 43762:foo.bar.com, and
rich>    you haven't generated numbers that high yet, then you're
rich>    right, we don't have any way to recognize that this wasn't
rich>    us.
rich> 
rich> *Conclusion:* using /serial:repostory-name/ would probably
rich> require some level of security on a repository basis.

Another conclusion is that your digging yourself into security-related
problems that aren't needed in the first place.

rich> Instead of simply accepting all revisions from a particular
rich> repository, we may need to list allowable repositories and/or
rich> make some attempt to verify that a respository with whom we are
rich> communicating really is the repository we think it is.
[...]
rich> In general, this is probably a good thing in the long run as it
rich> allows repository administrators, (ie, developers), the ability
rich> to fine tune and restrict which data they accept from whom.

monotone does authenticate changes.  Every revision in a monotone
repository is signed with the committer's key.  For that revision to
be accepted in my database, I must tell my monotone process that I
accept things signed with that key, of which I must have the public
half.

In message <address@hidden> on Tue, 19 Apr 2005 08:54:02 -0700, "K. Richard 
Pixley" <address@hidden> said:

rich> The same way monotone currently enforces branch naming.

monotone doesn't enforce any branch naming.  I can name my branches
'foo', 'bar', 'cookie' and 'oh-sexy-baby' if I wish to do so.  It's
not wise if I eventually want to share my development with others over
a wide-spread network, but that's a different matter.

So it's not monotone that enforces it, it's my wish to socialise with
other developers.

It's *recommended* to use your domain name in some sort of creative
way, that's true.  That's not enforcing, though...

rich> Dunno.  Does monotone currently include information about which 
rich> repository initially spawned a particular delta?

Nope, and that's not interesting.  Every revision carries along the
key identity of the committer, however.  That's probably more
interesting than the particular host the revision came from.

rich> Monotone already relies conventionally on domain names for
rich> unique branch names.  In this sense, monotone already relies on
rich> a central authority.

Not really.  A central authority is an entity that decides for the
others what they should do.  There's no such central authority for
monotone per se.  However, our intelligence helps us make decisions
that helps the greater good (in this case, cooperation).  In the case
of branches, the monotone manual recommends to use a structure that's
already in place for other purposes.

If you think of a closed environment, like a software company, there's
absolutely nothing saying they have to follow the recommended branch
naming scheme.

rich> If domain names and the attendant hierarchical delegation of
rich> naming authority are sufficiently decentralized and sufficiently
rich> unique for this purpose, I submit that the same mechanism is
rich> sufficiently unique and sufficiently decentralized to support
rich> repository naming.

I still believe you are needlessly tangling yourself in security
issues that currently don't exist.

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