Re: [Monotone-devel] Re: Key identities...

[William Uther]

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