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

[William Uther]

On 06/11/2007, at 10:25 AM, Graydon Hoare wrote:

> Chad Walstrom wrote:
> > Jack Lloyd <address@hidden> wrote:
> > > What if keys were versioned, so multiple keys with id
> > > 'address@hidden' show up in displays as 'address@hidden<1>',
> > > 'address@hidden<2>', ...
> > Or 'address@hidden(ah6821h...), address@hidden(eybn861...)'.
> > Rather than enumerate and worry about order, just display enough  
> > info to
> > make it unique.
>
> Agreed. It's far past the day when this change occurred. It's just  
> sloth on our part.

I was thinking about this change... (I was looking at making it)

If you're going to have the key show up as "address@hidden<1>" and "address@hidden 
<2>" when there are multiple keys, why not just make the user "genkey address@hidden 
<2>" when they generate the new key?

It would have the same effect.  And it means no coding changes  
required.  When someone generates a new key, it will mean some work  
for everyone else to trust the new key, BUT this would have had to  
happen anyway, or else you have security hole.

The problems we had with the current system were people trying to get  
back their old key.  I think we need to be more explicit that this  
*isn't possible*.  And I think we need to be more pro-active about  
stopping people that try, and directing them to make a new key with a  
new name. :)

We could make 'keygen' take another, integer, argument, and  
automatically attach it to the end of each key_id.  If not supplied,  
it would default to '1'.  Is that worthwhile?

I've just committed rev 4da3f70b40322b801436137980857d3316b8bc32.   
This was in response to Timothy Brownawell's comments in the "Remote  
public key hash unknown" thread that monotone was lax about checking  
key consistency - monotone used to allow different keys in the key  
store and the DB (and it would only warn on commit in this case - not  
error).  After my change, monotone will error if you try to use a key  
that is inconsistent between the key-store and the DB.  I also changed  
'list keys' so that it prints out all inconsistent keys at the end of  
the list.

Hopefully this will help stop more people getting into trouble.

Be well,

Will          :-}