Re: libidn2 0.13

[Tim Rühsen]

On Montag, 2. Januar 2017 12:11:15 CET Simon Josefsson wrote:
> Dennis Clarke <address@hidden> writes:
> >> Duh, sorry.  Yes indeed.  Watch me get it right in the 0.14 release :-)
> > 
> > Actually I have been watching the fray lately with interest and popcorn
> > and waiting for the dust to settle. I have to compile your releases on
> > some seriously strict POSIX systems and using the Oracle Studio 12.5 set
> > of compilers.  So once the dust settles then I grab the release and give
> > it a build/test cycle and report back what I see. The Oracle compilers
> > are really just the re-branded Sun ones and those will find errors and
> > syntax issues in places where we didn't even know those places exist. So
> > that can be very useful to fix up for portability sake.
> 
> Try 0.14.  It is now in Debian, which is a good test of some
> cross-architecture portability.  I'm sure there are other cross-platform
> issues remaining, but testing and reports are needed at this point to
> fix them.
> 
> I would like to add better APIs to actually make the library more usable
> for applications though.  Maybe we can take a look at the curl patch for
> libidn2 to see how the library would be used in reality.  In summary:

I maintain libpsl, wget and wget2 which use libidn2. I will update these 
projects to use the new TR46 code. Debian's libpsl is currently built with 
libicu (libicu | libidn2 | libidn selectable at built time), I will change 
that to libidn2 in the next days.

> * APIs more like libidn's that take a full domain name and do proper
>   operations on them.  In several forms, UTF-8, USC-32, locale encoded,
>   etc.
> 
> * APIs to decode a IDNA2008 domain from ACE to Unicode format.  That is
>   not described by the IDNA2008 RFCs, interestingly enough, but I
>   suspect people will want it, hah!

Wget used to use ACE decoding from libidn, but only for logging/displaying 
purpose. Since we switched to libidn2, the UTF-8/locale named will not be 
displayed any more :-). With such a function I would reactivate the logging 
code.

> Eventually maybe we could get curl to link to libidn2 for IDNA2008+TR46.
> If they want that.  They have to figure out whether they want IDNA2003
> or IDNA2008.  Or both.  It could be a switch.  'curl --idna2003
> fußball.de' or 'curl --idna2008 fußball.de' or 'curl --idna2008tr46
> fußball.de' or 'curl --idna2008tr46traditional' fußball.de'.  'curl
> fußball.de' could toss a coin to decide.

AFAIK, curl uses libidn2 only since a few weeks. There was a discussion 
ongoing about IDN security. That was one of the reasons, I wrote the TR46 
code. Daniel Stenberg (curl maintainer) even suggested to built curl without 
IDN to avoid security issues with non-tr46 IDNA.

IMO, all applications that use DNS lookups should be updated to use TR46 
transitional.
There are still uses for IDNA2003 - e.g. as Nikos Mavrogiannopoulos found out, 
domain names in TLS certificates are still encoded by IDNA2003. 

Tim

signature.asc
Description: This is a digitally signed message part.