This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Jan 19 14:17, Eric Blake wrote:
> 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.

Question: Why is that needed outside of testcases?  If you called
newlocale you know how it has been constructed.  The info should be
available.  I have no problems to take glibc emulating stuff, but is
there a real-world example?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]