[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: Key identities...
From: |
William Uther |
Subject: |
Re: [Monotone-devel] Re: Key identities... |
Date: |
Mon, 19 Nov 2007 11:55:13 +1100 |
On 19/11/2007, at 5:07 AM, Stephen Leake wrote:
Lapo Luchini <address@hidden> writes:
Richard Levitte wrote:
I won't deny that William's change is going to make a difference,
but
I question if it will be *enough* of a difference.
IMHO as creation of more keys with same name will always be
possible (in
disconnected spaces),
I agree. The question is how you deal with this.
Oh, and I should say that I'm not against the change. I just decided
that I wasn't going to bother myself, because I decided it wouldn't
make as big a difference as I first thought.
Ah, right. I can create a key with name "foobar" in my local database,
and so can my colleague. That collision won't be detected until we
both sync with the central database. At that point, it's very
inconvenient to go back, change one of the names, and clean up.
Let's look at some use cases here:
1a. A user makes a key. They commit some stuff and push it to
someone else. They lose their key. They decide to create another one
with the same name and try to use it.
1b. A user makes a key. They commit some stuff and push it to
someone else. Dastardly Dan comes along to try and subvert the
repository. Dan generates a new key with the same name as the user
and tries to use it.
Note that 1a. and 1b. are indistinguishable to a third party. In this
case we have three options,
i) Assume we're case 1a and let things go ahead.
ii) Let things go ahead, but issue a warning of some form (e.g.
attach a new label to the nodes to make them display uniquely)
iii) Error as soon as we can when the new key is discovered. In
case 1a, the user then has to generate a new key with a different ID
and continue. The end result is similar to ii), in that the string
now displayed is similar to the old key with a label attached, but
this system is a little more 'in your face' about the error.
I would hope that in either case 1 a or b the new key should be
discovered very quickly. e.g. Most users pull the remote DB before
their first commit. That db will have the old public key in it. When
they try and make their first commit with the new key, monotone will
now complain and refuse to commit. This is part of the change I
recently made. Prior to that change, monotone would warn about the
issue, but then allow the commit. Depending upon the sync method, it
was even possible for the revision signed with the new key to make it
into the remote db. I have run across this with a user here and this
late discovery is a real pain - I hope it is much less of an issue now.
More use cases:
2a. A user makes a key at work. The commit some stuff and push it to
someone else. They then start on a new project at home. They make a
key for home, using the same ID. They push it to yet another person.
They keep working on the two projects, at home and at work, for a
while. After a period they try to merge these two separate projects.
2b. As quoted above. There is a central project. A user checks it
out, generates a key, makes a few local commits but doesn't sync.
Then they go home, check out the project again, make a few more local
commits, sync. When they get back to work, they sync.
In use case 2, there is an issue. Again, we have the same outcomes as
before:
i) Just let the user have multiple keys. As before, this is a
security hole.
ii) Let the user have multiple keys, but attach a label to them.
iii) Error. There are solutions here, but they're ugly.
Summary:
The proposal to allow multiple keys in a database solves use case 2
more cleanly than the current system. I don't think that is a common
use case however. Use case 1a is where I've seen most people get into
trouble. Hopefully the new checks will catch those problems early.
Cheers,
Will :-}
- Re: [Monotone-devel] Key identities..., (continued)
- Re: [Monotone-devel] Key identities..., Jack Lloyd, 2007/11/05
- Re: [Monotone-devel] Key identities..., Chad Walstrom, 2007/11/05
- [Monotone-devel] Re: Key identities..., Graydon Hoare, 2007/11/05
- Re: [Monotone-devel] Re: Key identities..., William Uther, 2007/11/18
- Re: [Monotone-devel] Re: Key identities..., Jack Lloyd, 2007/11/18
- Re: [Monotone-devel] Re: Key identities..., William Uther, 2007/11/18
- Re: [Monotone-devel] Re: Key identities..., Stephen Leake, 2007/11/18
- Re: [Monotone-devel] Re: Key identities..., Richard Levitte, 2007/11/18
- [Monotone-devel] Re: Key identities..., Lapo Luchini, 2007/11/18
- Re: [Monotone-devel] Re: Key identities..., Stephen Leake, 2007/11/18
- Re: [Monotone-devel] Re: Key identities...,
William Uther <=
- Re: [Monotone-devel] Re: Key identities..., Stephen Leake, 2007/11/19
- Re: [Monotone-devel] Re: Key identities..., Richard Levitte, 2007/11/18