[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] internalize_rsa_keypair_id()
From: |
Zack Weinberg |
Subject: |
Re: [Monotone-devel] internalize_rsa_keypair_id() |
Date: |
Sun, 26 Jul 2009 21:10:24 -0700 |
On Sun, Jul 26, 2009 at 4:36 PM, Timothy Brownawell<address@hidden> wrote:
> 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.
I recall asking Graydone this many moons ago and being told that it
was basically historical junk. And around the same time I surveyed a
bunch of monotone databases and couldn't find anything that wasn't
plain ASCII. You've maybe got a bigger data set with your hosting
service, though.
In principle I would be glad to see all of that go. However, two
cautions: We are getting Unicode normalization (to some schema or
other) as a side effect. We maybe don't need that anymore if keys are
indexed by fingerprint rather than human-readable name, but I would
think carefully about the consequences of a visual collision for each
thing-in-the-database that loses normalization.
Also, we are using libidn as a wrapper around libiconv (via
stringprep_convert) as well as for ACE, and we *need* (but don't have)
better Unicode awareness in several areas (e.g. pathnames) that libidn
might be able to help with -- I haven't looked at its full API though.
zw