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

[Timothy Brownawell]

On Fri, 2009-08-14 at 11:32 +0200, Thomas Keller wrote:
> Timothy Brownawell schrieb:
> > I think branch net.venge.monotone.keys-by-hash is ready now.
> > 
> > The central change is that certs contain a key hash instead of a key
> > name, to get rid of the problem with key collisions.
> > 
> > Since this explicitly allows for duplicate key names, hooks that operate
> > on keys get a table containing "id" (the key hash), "name" (a local
> > name, given by another hook), and "given_name" (the name given when
> > creating the key).
> 
> What exactly is the local name? Something like a "local alias" for a
> unique key?

Yes. The idea is that when you do end up with multiple keys with the
same name, there's a way to tell them apart other than remembering the
hash. Ideally this would be some sort of policy-branch thing, but those
don't exist yet so it's a hook.

> > 'automate certs' prints the key hash where it printed the key name
> > before, and 'automate keys' lists both local and given names instead of
> > only one name.
> 
> I've checked 'automate certs' output and saw that only for new revisions
> the key hash is outputted
> 
>       key [1aaecf3a7c227e5545b0504aea5d3716d3128117]
> signature "ok"
>      name "author"
>     value "address@hidden"
>     trust "trusted"
> 
> while for old revisions key still points to the plain key name
> 
>       key "address@hidden"
> signature "ok"
>      name "author"
>     value "Timothy Brownawell  <address@hidden>"
>     trust "trusted"
> 
> Do you think its a good idea to mix both output types together?

Strange. It doesn't look like it should be able to print the key name
like that.

  basic_io::printer pr;
  for (size_t i = 0; i < certs.size(); ++i)
    {
      basic_io::stanza st;
...
      encode_hexenc(identity.id.inner(), keyid_enc);
      st.push_hex_pair(syms::key, keyid_enc);
...
      st.push_str_pair(syms::signature, stat);
      st.push_str_pair(syms::name, name());
      st.push_str_pair(syms::value, tv());
      st.push_str_pair(syms::trust, (trusted ? "trusted" :
"untrusted"));

      pr.print_stanza(st);
    }
  output.write(pr.buf.data(), pr.buf.size());



>  I'd have
> thought it would be better to do something like this:
> 
>       key "address@hidden"
>      hash [1aaecf3a7c227e5545b0504aea5d3716d3128117]
> signature "ok"
>      name "author"
>     value "address@hidden"
>     trust "trusted"
> 
>       key "address@hidden"
>      hash []
> signature "ok"
>      name "author"
>     value "Timothy Brownawell  <address@hidden>"
>     trust "trusted"
> 
> where [] stands for "not uniquely resolvable", i.e. this is a legacy
> cert. This way the impact for automate implementors is minimal, because
> the automate certs format gets only slightly extended.

All existing certs get resolved during 'db migrate', when it's still
only possible to have one key with a particular name. Something like:

  rename table revision_certs to tmp;
  create table revision_certs (...);
  insert into revision_certs (select key_hash, ...)
   from public_keys, tmp where signer = key_name;

So, "not uniquely resolvable" shouldn't be possible.

> I'll play around a bit more with your branch - looks cool so far.
> 
> Thomas.

Thanks for the feedback, will look into your other mail after work.