[Top][All Lists]

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

GNU Libidn 0.5.0 alpha released

From: Simon Josefsson
Subject: GNU Libidn 0.5.0 alpha released
Date: Sat, 26 Jun 2004 14:21:40 +0200
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)

Hello.  This release add some code to detect the "problem sequences"
discussed in UTC's public review issue #29.  To perhaps explain this
in less obfuscated terms, here follow some paragraphs from the manual:

      A deficiency in the specification of Unicode Normalization Forms
   has been found.  The consequence is that some strings can be
   normalized into different strings by different implementations.  In
   other words, two different implementations may return different
   output for the same input (because the interpretation of the
   specification is ambiguous).  Further, an implementation invoked
   again on the one of the output strings may return a different
   string (because one of the interpretation of the ambiguous
   specification make normalization non-idempotent).  Fortunately,
   only a select few character sequence exhibit this problem, and none
   of them are expected to occur in natural languages (due to
   different linguistic uses of the involved characters).

      A full discussion of the problem may be found at

      The PR29 functions below allow you to detect the problem
   sequence.  So when would you want to use these functions?  For most
   applications, such as those using Nameprep for IDN, this is likely
   only to be an interoperability problem.  Thus, you may not want to
   care about it, as the character sequences will rarely occur
   naturally.  However, if you are using a profile, such as SASLPrep,
   to process authentication tokens; authorization tokens; or
   passwords, there is a real danger that attackers may try to use the
   peculiarities in these strings to attack parts of your system.  As
   only a small number of strings, and no naturally occurring strings,
   exhibit this problem, the conservative approach of rejecting the
   strings is recommended.  If this approach is not used, you should
   instead verify that all parts of your system, that process the
   tokens and passwords, use a NFKC implementation that produce the
   same output for the same input.


GNU Libidn is an implementation of the Stringprep, Punycode and IDNA
specifications defined by the IETF Internationalized Domain Names
(IDN) working group, used for internationalized domain names.  The
library contains a generic Stringprep implementation that does Unicode
3.2 NFKC normalization, mapping and prohibitation of characters, and
bidirectional character handling.  Profiles for Nameprep, iSCSI, SASL
and XMPP 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.

Here are the compressed sources:   (1.8MB)   (1.8MB)

Here are GPG detached signatures:

Here are the build reports for various platforms:

Here are the MD5 and SHA1 signatures:

d13633479facc9163eb16db6f9662a3b  libidn-0.5.0.tar.gz
ec010fed2ae4843e5651239f15fddbba  libidn-0.5.0.tar.gz.sig
6a4189656fbbc8efb65d5454e8e1ba7005ef639f  libidn-0.5.0.tar.gz
9fb995669d2c1cc8996beaaccf911193fb5545fe  libidn-0.5.0.tar.gz.sig

Noteworthy changes since version 0.4.9 (the last version announced here):

* Version 0.5.0 (unreleased)

** Functions to detect "normalization problem sequences" as per PR-29 added.
See the new chapter "PR29 Functions" in the manual
(doc/libidn.{ps,pdf,html}) for more information and the background
story.  An external link that discuss the problem is

** More translations.
Added Esperanto (by Edmund GRIMLEY EVANS).

** API and ABI is backwards compatible with the previous version.
pr29.h: ADD.  Prototypes for PR29 types and functions.
pr29_4, pr29_4z, pr29_8z: ADD.  New API entry points for PR29 functions.
Pr29_rc: ADD.  New error code enum type for PR29 functions.

reply via email to

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