Re: [SECURITY] libidn - locale specific error in test suite

[Eric Blake <eblake at redhat dot com>]

On 01/19/2017 12:19 PM, Corinna Vinschen wrote:

>>> The test comes from gnulib, so I'm familiar with ideas on how to try and
>>> whittle it down to a smaller self-contained test.  I'll see if I can
>>> spend a moment on it today.
>>>
>>
>> After stepping through a debugger, it looks like this is a bug in gnulib
>> and not cygwin.  Gnulib is trying to test that its own function
>> gl_locale_name() can track the use of uselocale() to set a thread-local
>> locale that overrides the global locale.  It has platform specific code
>> for various platforms (glibc uses nl_langinfo(), BSD uses querylocale(),
>> Sun uses getlocalename_l() - surprisingly none of the platforms use
>> nl_langinfo_l()!), then falls back to probing the environment.  As long
>> as cygwin lacked uselocale(), then probing the environment was correct.
>> But now that cygwin supports uselocale(), the gnulib code needs to add a
>> cygwin-specific clause to its list of various platform methods.
>>
>> I'll propose a patch to upstream gnulib, and cc this list - any project
>> using gnulib will have to backport that patch or wait for a new upstream
>> release of that project that uses newer gnulib if it wants to work
>> around the bug.
> 
> Thanks for letting us know!

Actually, Cygwin (or newlib) will need a patch, too.  glibc provides the
macro NL_LOCALE_NAME, which can be used as follows:

locale = newlocale(...);
uselocale(locale);
nl_langinfo_l(NL_LOCALE_NAME(LC_MESSAGES), locale);

to recover the name of the LC_MESSAGES portion of the locale object.

As Cygwin lacks that macro, there is NO way to access the locale name of
what went into constructing a thread-local locale without peeking into
the internal guts of the opaque locale_t object.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature