Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#6713 closed enhancement (fixed)

libidn-1.31

Reported by: bdubbs@… Owned by: bdubbs@…
Priority: high Milestone: 7.8
Component: BOOK Version: SVN
Severity: normal Keywords:
Cc:

Description (last modified by Fernando de Oliveira)

Security Update

New minor version

After this ticket has been closed, I discovered that it solved a security vulnerability.

CVE-2015-2059

Thus, I decided to change the ticket.

Users are advised to update to this version or, preferably, later. Book now is at version 1.32.

https://ftp.gnu.org/gnu/libidn/libidn-1.31.tar.gz

or

ftp://ftp.gnu.org/gnu/libidn/libidn-1.31.tar.gz

https://ftp.gnu.org/gnu/libidn/libidn-1.31.tar.gz.sig

https://lists.gnu.org/archive/html/help-libidn/2015-07/msg00011.html

or

http://git.savannah.gnu.org/gitweb/?p=libidn.git;a=blob_plain;f=NEWS;hb=HEAD

SHA1 0bb34003a0fe05a91e60d346803401f16c82a1fb libidn-1.31.tar.gz

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
Mavrogiannopoulos.

** 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
before.

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

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

Happy hacking,
Simon

Change History (3)

comment:1 by bdubbs@…, 9 years ago

Owner: changed from blfs-book@… to bdubbs@…
Status: newassigned

comment:2 by bdubbs@…, 9 years ago

Resolution: fixed
Status: assignedclosed

Fixed at revision 16238.

comment:3 by Fernando de Oliveira, 8 years ago

Description: modified (diff)
Priority: normalhigh
Note: See TracTickets for help on using tickets.