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). _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
