Re: [Monotone-devel] internalize_rsa_keypair_id()

[Timothy Brownawell]

On Sun, 2009-07-26 at 21:10 -0700, Zack Weinberg wrote:
> 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.

On further thought I'm not sure this would even need to be a schema
change, because the values are never ever decoded. Just drop the
encoding and note in NEWS that non-ascii names will actually work now.

It's not dropping the coding would turn my chineese cert names into
punycoded cert names and break my scripts that use them, because they
already show as punycoded cert names. The only effect would be on the
scripts generating the certs, which would get to actually match the
scripts using them.

So, now I'm proposing to drop the encoding and not try to migrate
anything. Because migrating would break as much stuff as not migrating.

> 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.

No ACE-encoded data there.

> 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.

* Keys
        We want to allow actual collisions, and I don't think
        a visual collision would be any worse. I'm also making
        'ls certs' and 'ls tags' print the first few digits of
        the key hash, and lua hooks taking keys as arguments
        get a table that includes the full hash.

* Var domains
        These are purely local, so no implications.

* Cert names
        People would be able to produce certs which would be
        "invisible" to programs but would look real to humans
        inspecting things. This can already be done by putting
        spaces at the end of your cert names, so I don't think
        it adds any implications.

        I think the only impact this could have would be the same
        as sending fake commit notifications, and borked certs are
        somewhat easier to trace than fake email.


> 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.

k, I won't go muddling around in our autoconf stuff trying to remove it
then.