Re: New version of the libidn2 patch

[Florian Weimer <fw at deneb dot enyo dot de>]

* Zack Weinberg:

> On Sun, Apr 1, 2018 at 2:54 PM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 03/15/2018 11:03 PM, Florian Weimer wrote:
>>>
>>> For some reason, libidn2 does not fail the conversion, but uses the
>>> replacement character '?' for unencodable characters.  This will have to be
>>> fixed in libidn2 eventually.>
>>
>> This has now been fixed in upstream libidn2.
>
> I don't think I can comment usefully on any of the code changes but I
> have some concerns about the behavior in some of the failure cases.
> Most importantly, I don't understand exactly what we do if the
> application calls getaddrinfo, passing AI_IDN, with a name that would
> be changed by punycoding it, but libidn2 is not available.  The NEWS
> makes it sound like we might transmit a raw non-ASCII name to the DNS
> server in that case, and I think we shouldn't do that.

Only very few applications currently use AI_IDN.  This means that if
the user enters such a name with a non-AI_IDN application, exactly the
same thing will happen.  That's why I thought the fallback behavior
made sense.

It's probably more of a performance optimization to change this: We
could check the name for non-ASCII characters (and backslashes,
because interesting things happen with them) and load and call into
libidn2 only if there are such non-ASCII characters.

> I also wonder if we shouldn't somehow detect and refuse to use
> versions of libidn2 without all the necessary bugfixes.

The ??? transcoding bug is probably something approaching a security
bug, but I'm not sure if it can actually be triggered in a UTF-8
locale.  (The point is that for getnameinfo and AI_CANONIDN, the ?
replacement character is introduced *after* the meta-character checks
in nss_dns, and pathname expansion in the shell could result in all
kinds of unwanted characters.)  The other bugs are really benign, and
there's no evidence that they have been encountered in the wild.