[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] newbie question - SHA1 vs serials
From: |
K. Richard Pixley |
Subject: |
Re: [Monotone-devel] newbie question - SHA1 vs serials |
Date: |
Tue, 19 Apr 2005 11:56:32 -0700 |
User-agent: |
Mozilla Thunderbird 1.0.2 (Macintosh/20050317) |
Richard Levitte - VMS Whacker wrote:
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.
That's certainly possible.
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.
Understood. However, I can also see a desire to allow only those such
changes which also come from a trusted place; that is, a refinement of
what will be accepted.
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...
Exactly so. And naming of repositories could follow precisely the same
procedure. If it's sufficiently unique and sufficiently distributed for
use in branch naming, then I submit that it's sufficiently unique and
sufficiently distributed for repository naming.
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.
I might care about the host as well. I learn a lot from determining
whether you checked this change in initially from your laptop Macintosh
or from your desktop freebsd box or from our hardware in development
which happens to be an embedded arm running Linux. I also learn where
to look if I want to complete a change someone else may have
unintentionally committed incompletely.
I also care if I want to track the geographic distribution of a
particular revision.
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.
Understood and agreed.
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.
And the same would be true for repository names.
If they later decided to share code with another company, and found that
they had collisions on branch names or repository names, we'd simply
write it off as short sightedness on their part.
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.
Heard.
I'm not currently a monotone user or developer. I like many of the
features offered though I'm thinking SHAT1 for version id's is going to
be a hard sell.
--rich
- [Monotone-devel] newbie question - SHA1 vs serials, K. Richard Pixley, 2005/04/19
- Re: [Monotone-devel] newbie question - SHA1 vs serials, Jon Bright, 2005/04/19
- Re: [Monotone-devel] newbie question - SHA1 vs serials, K. Richard Pixley, 2005/04/19
- Re: [Monotone-devel] newbie question - SHA1 vs serials, Timothy Brownawell, 2005/04/19
- Re: [Monotone-devel] newbie question - SHA1 vs serials, Will Newton, 2005/04/19
- Re: [Monotone-devel] newbie question - SHA1 vs serials, K. Richard Pixley, 2005/04/19
- Re: [Monotone-devel] newbie question - SHA1 vs serials, Richard Levitte - VMS Whacker, 2005/04/19
- Re: [Monotone-devel] newbie question - SHA1 vs serials,
K. Richard Pixley <=
- Re: [Monotone-devel] newbie question - SHA1 vs serials, Matt Johnston, 2005/04/19
- Re: [Monotone-devel] newbie question - SHA1 vs serials, Jon Bright, 2005/04/19
- Re: [Monotone-devel] newbie question - SHA1 vs serials, K. Richard Pixley, 2005/04/19
- Re: [Monotone-devel] newbie question - SHA1 vs serials, tekHedd, 2005/04/19
- Re: [Monotone-devel] newbie question - SHA1 vs serials, K. Richard Pixley, 2005/04/19
- Re: [Monotone-devel] newbie question - SHA1 vs serials, Richard Levitte - VMS Whacker, 2005/04/19
- Re: [Monotone-devel] newbie question - SHA1 vs serials, K. Richard Pixley, 2005/04/19
- Re: [Monotone-devel] newbie question - SHA1 vs serials, Richard Levitte - VMS Whacker, 2005/04/19
- Re: [Monotone-devel] newbie question - SHA1 vs serials, K. Richard Pixley, 2005/04/19
- Re: [Monotone-devel] newbie question - SHA1 vs serials, Jon Bright, 2005/04/19