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 monotoneUnderstood. 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.
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.
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.In message <[EMAIL PROTECTED]> on Tue, 19 Apr 2005 08:54:02 -0700, "K. Richard Pixley" <[EMAIL PROTECTED]> 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?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.
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 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 mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
