This is the mail archive of the
mailing list for the glibc project.
Re: What to do about libidn?
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 11 Nov 2016 15:00:49 -0500
- Subject: Re: What to do about libidn?
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org>
On 11/08/2016 06:52 AM, Florian Weimer wrote:
> 7. On the glibc side, IDN only applies to getaddrinfo, is opt-in via
> AI_IDN, and requires a non-ASCII locale. Everything else sends
> unencoded bytes over the wire via DNS.
> What should we do to improve this situation? I would really like to
> remove AI_IDN, but this is likely not an option.
> Should we remove our internal copy and try to dlopen libidn2? Maybe
> falling back to libidn if libdn2 is unavailable? Bundle libidn2?
> Write our own implementation?
I think that AI_IDN was layered at the wrong level.
Applications need much more rich APIs to handle IDN than we give them.
I'm in favour of removing AI_IDN support for _new_ binaries, which means
versioning and stripping out AI_IDN support in new version of getaddrinfo.
For existing binaries I think we must continue to provide the support
we have but freeze out the code so we can eventually remove it.
If there are security issues in using the existing code as-is then I think
a dlopen of libidn (the system library with fixes) is acceptable.
Transitioning to libidn2 doesn't seem like a feasible solution.
I think this lines up with Joseph's recommendations.