[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Merging branch to allow duplicate key names, have c
From: |
Timothy Brownawell |
Subject: |
Re: [Monotone-devel] Merging branch to allow duplicate key names, have certs use key hash |
Date: |
Fri, 14 Aug 2009 13:12:09 +0000 |
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.
Re: [Monotone-devel] Merging branch to allow duplicate key names, have certs use key hash, Timothy Brownawell, 2009/08/20