[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Libidn 1.31 released

From: Simon Josefsson
Subject: Libidn 1.31 released
Date: Wed, 08 Jul 2015 23:33:00 +0200
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)

GNU Libidn is a fully documented implementation of the Stringprep,
Punycode and IDNA specifications.  Libidn's purpose is to encode and
decode internationalized domain name strings.  There are native C, C#
and Java libraries.

Noteworthy changes since the last release (from NEWS file):

* Version 1.31 (released 2015-07-08) [beta]

** libidn: stringprep_utf8_to_ucs4 now rejects invalid UTF-8. CVE-2015-2059
This function has always been documented to not validate that the
input UTF-8 string is actually valid UTF-8.  Like the rest of the API,
when you call a function that works on UTF-8 data, you have to pass it
valid UTF-8 data.  Application writers appear to have difficulties
using interfaces designed like that, as bugs triggered by invalid
UTF-8 has been identified in a number of projects (jabberd2, gnutls,
wget, and curl).  While we could introduce a new API to perform UTF-8
validation, so that applications can easily implement the proper
checks, this appear error prone because there is a risk that the check
will be forgotten.  Instead, we took the more radical approach of
modifying the documentation and the implementation of the API.  The
intention is that all functions that accepts UTF-8 data should
validate it before use.  This will solve the problem for applications,
without needing to change them.  This change has the unfortunate
side-effect that Surrogate codes (see section 5.5 of RFC 3454) no
longer trigger the STRINGPREP_CONTAINS_PROHIBITED error code but
instead will trigger the newly introduced STRINGPREP_ICONV_ERROR error
code, as the gnulib/libunistring-based code that we use to test
UTF-8-compliance rejects Surrogate codes.  We hope that this is an
acceptable cost to live with in order to improve application security.
We welcome feedback on this solution, and we are marking this release
as beta rather than stable to signal that we may reconsider this
approach if people disagree.  Reported by several people including
Thijs Alkemade, Gustavo Grieco, Daniel Stenberg, and Nikos

** libidn: Added STRINGPREP_ICONV_ERROR error code.

** libidn: Workaround valgrind/gcc/glibc issue.
Valgrind reported a 'Invalid read of size 4' that was caused by
optimized strlen implementation.  Reported and patch by Alessandro
Ghedini <address@hidden>.

** build: Use LOG_COMPILER instead of TESTS_ENVIRONMENT to fix valgrind use.
Errors caught by valgrind did not always trigger 'make check' failures

** i18n: Updated Danish translation.
Thanks to Joe Hansen.

** API and ABI is backwards compatible with the previous version.

The C library contains a generic Stringprep implementation.  Profiles
for Nameprep, iSCSI, SASL, XMPP and Kerberos V5 are included.  Punycode
and ASCII Compatible Encoding (ACE) via IDNA are supported.  A mechanism
to define Top-Level Domain (TLD) specific validation tables, and to
compare strings against those tables, is included.  Default tables for
some TLDs are also included.

The Stringprep API consists of two main functions, one for converting
data from the system's native representation into UTF-8, and one
function to perform the Stringprep processing.  Adding a new Stringprep
profile for your application within the API is straightforward.  The
Punycode API consists of one encoding function and one decoding
function.  The IDNA API consists of the ToASCII and ToUnicode functions,
as well as an high-level interface for converting entire domain names to
and from the ACE encoded form.  The TLD API consists of one set of
functions to extract the TLD name from a domain string, one set of
functions to locate the proper TLD table to use based on the TLD name,
and core functions to validate a string against a TLD table, and some
utility wrappers to perform all the steps in one call.

Libidn is developed for the GNU/Linux system, but runs on over 20 Unix
platforms (including Solaris, IRIX, AIX, and Tru64) and Windows.  The
library is written in C and (parts of) the API is also accessible from
C++, Emacs Lisp, Python and Java.  A native Java and C# port is

Also included is a command line tool, several self tests, code examples,
and more.

Improving Libidn is costly, but you can help!  We are looking for
organizations that find Libidn useful and wish to contribute back.  You
can contribute by reporting bugs, improve the software, or donate money
or equipment.

Commercial support contracts for Libidn are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult AB, a
Stockholm based privately held company, is currently funding Libidn
maintenance.  We are always looking for interesting development
projects.  See for more details.

The project page of the library is available at:

All manual formats are available from:

Specifically, the following formats are available.

The main manual: - HTML format - PDF format

API Reference manual: - GTK-DOC HTML - GTK-DOC PDF

Doxygen documentation: - HTML format - PDF format

JavaDoc output for the Java API:

If you need help to use Libidn, or want to help others, you are
invited to join our help-libidn mailing list, see:

Here are the compressed sources (3.4MB):

Here are GPG detached signatures:

Here are the SHA-1 and SHA-224 signatures:

0bb34003a0fe05a91e60d346803401f16c82a1fb  libidn-1.31.tar.gz
70b14fa49c875b4bc9919e50c994968e34c965bbd20f8c9bef0d6431  libidn-1.31.tar.gz

We also provide Windows binaries built using MinGW-w64 with the build
script windows/, for 32-bit and 64-bit x86 architecures:

Here are the SHA-1 and SHA-224 signatures:



The software is cryptographically signed by the author using an OpenPGP
key identified by the following information:

pub   3744R/54265E8C 2014-06-22
      Key fingerprint = 9AA9 BDB1 1BB1 B99A 2128  5A33 0664 A769 5426 5E8C
uid                  Simon Josefsson <address@hidden>

The key is available from:

Code coverage, clang-analyzer output, and cyclomatic code complexity charts:

Happy hacking,

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]