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

[William Uther]

On 18/11/2007, at 6:46 PM, Jack Lloyd wrote:

> On Sun, Nov 18, 2007 at 06:20:08PM +1100, William Uther wrote:
> > 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?
>
> How? What is to stop me from running
>
> mtn genkey address@hidden
>
> and the commiting changes with it?

Um, well, same as now.

Being more specific, if you have two identical keys then whichever key  
gets into the DB first is the one that is trusted.  If you did this  
and tried to push to the monotone.ca monotone database, I think your  
revision would be accepted, but your new key would not be (I haven't  
actually checked myself).  Then when people download the revision it  
gets ignored because it isn't signed by a key in their DB.  If you  
committed a child revision of the 'bogus' revision, signed with your  
own key, then that revision will be trusted by whomever trusts your  
key, regardless of the history of the revision.

All I was suggesting is that we could add (voluntary) numbers to the  
end of the keys.  At the moment you can type

mtn genkey address@hidden<2>

and you'll get a key, and monotone will let you commit to your local  
db with it and sync to the main monotone db.  It is up to the people  
looking at the revs to know that the willu..<2> is not the same as the  
original willu key.

If this breaks anything then there is a severe problem with the  
current system, because I'm proposing only cosmetic changes.

> Whatever instance of monotone is generating the key only has some set
> of local knowlege and has no idea if when I tell it to generate a new
> key with a particular ID if that ID has been assigned before. Unless
> someone sets up some sort of nameservice such that duplicates can be
> rejected. http://en.wikipedia.org/wiki/Zooko's_triangle

Yeah.  Same as now.  But I'm assuming that if I need to generate a new  
key, I'll know what key number I was up to so I can generate the next  
in the series.  If I get it wrong, then I'd expect monotone to start  
giving the same sorts of errors as if someone was trying to spoof a  
key.  In that case I can generate the next key in the sequence, re- 
sign my revisions and keep going.

> > 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?
>
> And what happens if someone decides to lie? Or even just messes up and
> puts the wrong integer?

Well, if they generate a key under someone else's name with an integer  
attached, then they have that key. Same as now.  It is up to the  
people looking at the logs to recognise the new key as different to  
the original.  Same as now.

If they generate a new key that has the same name as an old key, then  
monotone should catch that as soon as possible and point out the  
problem to all involved.  The commit I made earlier today should help  
with this.

The proposal that was being floated earlier in this thread was to  
allow multiple keys with the same label in the database (by indexing  
on key hash rather than key id).  It was then pointed out that for  
display to the user you'd have to differentiate the keys to stop  
security problems (e.g. someone might generate a new key with the same  
id as yours and commit a revision "under your name").

All I'm saying is that we've come full circle, and no change is  
required.  Once you have the original names always having some extra  
identifier attached, why not put the identifier in the name itself?   
I'm suggesting _less_ change to the status quo than the previous  
proposal, because I can't see what advantage the previous proposal  
brings.

The only change the status quo I did suggest was to alter the UI of  
one command a little to suggest a common workflow.

> Do not prohibit what you cannot prevent.

I'm not trying to.  I think there has been a miscommunication somewhere.

Will        :-}