New version of the libidn2 patch

[Florian Weimer]

On 04/01/2018 09:42 PM, Florian Weimer wrote:
> * 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.

Here's a patch implementing this.  I'd like to commit this separately 
because it is slightly less well-tested than the rest.

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

It also papers over part of the transcoding bug because it will 
recognize invalid multi-byte sequences and not pass them to libidn2.

Thanks,
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: idna-check.patch
Type: text/x-patch
Size: 12394 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20180404/c451c24c/attachment.bin>