[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libidn2 0.13
Re: libidn2 0.13
Mon, 02 Jan 2017 22:17:49 +0100
KMail/5.2.3 (Linux/4.8.0-2-amd64; KDE/5.28.0; x86_64; ; )
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,
> * 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
> 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
There are still uses for IDNA2003 - e.g. as Nikos Mavrogiannopoulos found out,
domain names in TLS certificates are still encoded by IDNA2003.
Description: This is a digitally signed message part.