Re: [PATCH COMMITTED] Switch IDNA implementation to libidn2 [BZ #19728] [BZ #19729] [BZ #22247]

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 23/05/2018 16:33, Florian Weimer wrote:
> On 05/23/2018 07:51 PM, Adhemerval Zanella wrote:
> 
>> So in this case we should at least document this better, commit message does
>> not have anything regarding it and NEWS update just states "[...] libidn2
>> version 2.0.5 or later is recommended. [...]" which does not really state
>> why 2.0.5 is preferred.
> 
> I thought that obvious: It has fewer bugs.  This dragged on for so many months because we kept finding issues that needed addressing, and only with the 2.0.5 release, we have something that is close both to the WHATWG recommendations (which isn't what browsers implement) and what is needed on some enterprise networks.
> 
> HJ tested with Fedora 28 libidn2 which has backports, so he reported only comparatively few test failures.
> 
>> Also, reading the newer tests does give any indication why 2.0.5 is required
>> to fully compliance nor they check libidn2 version.  To one involved in glibc
>> developments it should be straightforward to relate possible test-suite to
>> related error, but I still think that indicating that system tests libidn is
>> the culprit nor glibc itself is a better error output.
> 
> There are comments in the test case which indicate what is being tested (non-transitional mode, Unicode TR 46 mode).  These are areas where we pushed libidn2 to change defaults.
> 
> Due to the backports from some distributions, mentioning specific libidn2 versions could be misleading.
> 
> Immediately after the commit, I added a note <https://sourceware.org/glibc/wiki/Release/2.28#libidn2_is_a_recommended_dependency>.  Isn't this sufficient?
> 
> Thanks,
> Florian

What was not immediate obvious to me (and H.J. Lu I would say) was which 
kind of issues to expect in a non conforming environment, neither that 
resolv/tst-resolv-ai_idn should fail in such scenarios.  It it just for 
future references it would be good to have reference that it might be 
triggered by a faulty libidn2 installation (which this thread should 
be enough if someone cross this very issue).