Re: [Monotone-devel] Merging branch to allow duplicate key names, have certs use key hash

[Timothy Brownawell]

On Fri, 2009-08-14 at 12:20 +0200, Thomas Keller wrote:
> Timothy Brownawell schrieb:
> > I think branch net.venge.monotone.keys-by-hash is ready now.
> 
> Some more observations:
> 
> 1) It might be helpful to output the filename / hash of a just generated
> key and probably make the unique file a bit easier to grasp for people:
> 
> $ ./mtn genkey address@hidden
>                     enter passphrase for key ID address@hidden
> (...):
> confirm passphrase for key ID address@hidden (...):
> mtn: generating key-pair 'address@hidden'
> mtn: storing key-pair 'address@hidden' in /Users/tommyd/.monotone/keys/

'genkey' will now output the key hash.

   mtn: storing key-pair 'address@hidden' in /home/tbrownaw/...
   mtn: storing public key 'address@hidden' in /home/tbrownaw/...
   mtn: key 'address@hidden' has hash 'e4ebc8aa[snip]'



> $ ls -l ~/.monotone/keys
> -rw-------  1 tommyd  admin   1,2K 14 Aug 11:47
> 4ba4226e14c9bb57a2daf9698e76b8149256f20e
> 
> What about a filename like <keyname>.<hash> or something similar?

It's changed to do this now.

> 2) If mtn genkey stores keys as unique files, why should it prevent to
> create a key with the same name again? Maybe I want to work with
> different keys in different (unrelated) projects - it would be cool to
> just have a --force-nonunique-keyname or something option to (automate)
> genkey or at least give the user the hint "if you really want to do
> this, temporarily move the conflicting key under $HOME/.monotone/keys
> out of the way"

Done, it's called --force-duplicate-key.

> 3) I now have two keys with the same key name "address@hidden" in
> my local key store. My (old, unaltered) get_branch_key() hook still
> points to "address@hidden" by default. If I try to make a test
> commit without the --key option I get a weird exception:
> 
> mtn: beginning commit on branch 'biz.thomaskeller.keyhash-0.45-test'
> mtn: fatal:
> boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::io::too_many_args>
> >: boost::too_many_args: format-string referred to less arguments than
> were passed
> 
> (The full --debug output is attached)

That particular error turns out to mean that I'd put '%n' instead of
'%d' for a number in an error message. With that fixed, you should now
get an error about having 2 keys with that name.

> 4) I've added the following hook into my monotonerc:
> 
> function get_local_key_name(identity)
>         if identity.id == "4ba4226e14c9bb57a2daf9698e76b8149256f20e" then
>                 return "my.new.key"
>         end
>         return identity.given_name;
> end
> 
> to make the "new key" distinguishable from the old one. If I try to
> specify the local name of the key during commit, however, monotone tells me
> 
> $ ./mtn ci --key my.new.key -m "test"
> mtn: beginning commit on branch 'biz.thomaskeller.keyhash-0.45-test'
> mtn: misuse: there is no key named 'my.new.key'
> 
> Whats even weirder though is that mtn doesn't seem to pick up my new
> local_name:
> 
> $ ./mtn au keys
> ...
>             hash [4ba4226e14c9bb57a2daf9698e76b8149256f20e]
>       given_name "address@hidden"
>       local_name "address@hidden"
>  public_location "keystore"
> private_location "keystore"

It seems that none of the tests actually looked at the 'id' part of the
key identity table, and it was getting binary data instead of a hex
string. This is fixed now, including making one of the tests check for
it.

> mtn ls keys additionally outputs two warnings:
> 
> mtn: warning: Some key names refer to multiple keys
> mtn: warning: Mismatched Key: address@hidden
> 
> What does the second one means?

I changed it to be 'P(F("Duplicate Key: %s") % name);' It lists the
individual key names that there are more than one key for, but the
message text was from before when it warned about having one key in the
key store and a different one in the db.

> 5) There is a small typo in monotone.texi, `get_author (branchname,
> keyidentity)` should be `get_author (branchname, key_identity)`

Fixed.

> 6) What about the hooks `get_branch_key` and `get_netsync_key`? Is it
> allowed now these hooks return a local name or key ID or do we still
> assume the given_name here?

What they return is treated the same as a key given on the command line
-- it's tried as a key_id first, and if it's not [[:xdigit:]]{40} then
it's tried as a local name and then a given name.

> 7) Should the format of read-permissions / write-permissions be extended
> to allow listing of key ids / local names as well? I found no hints in
> the branch's monotone.texi that anything has been changed there...

Those entries are tried first as key_id's, then as local names. They're
not tried as given key names, since that seems a bit dangerous.


Again, thanks for the review.