[Monotone-devel] internalize_rsa_keypair_id()

[Timothy Brownawell]

Is there any particular reason that we ACE-encode[1] the domain part
(after the '@') of key names on input, and then never decode them (the
only place that externalize_rsa_keypair_id() is ever called is when
writing _MTN/options)? I'm working on making certs link to keys by hash
instead of name, which seems like a perfect opportunity to also get rid
of this since the schema is changing anyway.

The ACE-encoding is *not* done for lua hooks that take/return key names.

We also do the exact same thing with cert names (but this can't be
gotten rid of until there's some other change that means all certs have
to be reissued anyway, like moving to a new hash or something), and we
encode var domains the same way but do decode them on output.


Is it reasonable to assume that there probably aren't any instances of
key names / cert names / var domains that aren't valid ASCII? For the
key names and cert names the lack of decoding makes me think people
would have complained here if they tried to use non-ASCII names, and I'm
not aware that nonstandard db vars are actually useful for anything. I
think these are the only things that we use libidna for, and it seems
like not a great idea to require linking against a library that's only
ever used during migration. Maybe check for the ACE prefix "xn--" during
migration and print an error like the changeset->roster migrator does
for unknown attributes?

[1] "ASCII-compatible encoding" from internationalized domain names,
http://www.faqs.org/rfcs/rfc3490.html

-- 
Timothy

Free public monotone hosting: http://mtn-host.prjek.net
If monotone breaks network compatibility you'll see it here
first (probably even before the new version shows up in your
distro's repositories).