[SECURITY] libidn

[SECURITY] libidn

[Yaakov Selkowitz]

Dr. Volker,

Several security vulnerabilities have been announced for libidn, which 
are fixed in 1.33:

https://lists.gnu.org/archive/html/help-libidn/2016-07/msg00009.html

-- 
Yaakov

Re: [SECURITY] libidn

[Dr. Volker Zell]

>>>>> Yaakov Selkowitz writes:

    > Dr. Volker,
    > Several security vulnerabilities have been announced for libidn, which are fixed
    > in 1.33:

    > https://lists.gnu.org/archive/html/help-libidn/2016-07/msg00009.html

Noted (and also your other mails), will work on it as soon as real work permits.

Ciao
  Volker

Re: [SECURITY] libidn

[Yaakov Selkowitz]

On 2016-09-30 01:43, Dr. Volker Zell wrote:
>>>>>> Yaakov Selkowitz writes:
>
>     > Dr. Volker,
>     > Several security vulnerabilities have been announced for libidn, which are fixed
>     > in 1.33:
>
>     > https://lists.gnu.org/archive/html/help-libidn/2016-07/msg00009.html
>
> Noted (and also your other mails), will work on it as soon as real work permits.

Ping?

-- 
Yaakov

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

[Dr. Volker Zell]

On 29.12.2016 21:49, Yaakov Selkowitz wrote:
> On 2016-09-30 01:43, Dr. Volker Zell wrote:
>>>>>>> Yaakov Selkowitz writes:
>>
>>     > Dr. Volker,
>>     > Several security vulnerabilities have been announced for 
>> libidn, which are fixed
>>     > in 1.33:
>>
>>     > 
>> https://lists.gnu.org/archive/html/help-libidn/2016-07/msg00009.html
>>
>> Noted (and also your other mails), will work on it as soon as real 
>> work permits.
>
> Ping?
>

Hi

Just tried packaging libidn-1.33 and found a locale specific error in 
the test suite (Which was working fine with my latest build). When 
running under strace I get:

....
--- Process 8320 thread 6244 created
--- Process 8320 loaded E:\bin\cygwin1.dll at 0000000180040000
     1       1 [main] test-localename (8320) 
**********************************************
    37      38 [main] test-localename (8320) Program name: 
D:\misc\src\cygwin\libidn-1.33-1.x86_64\build\lib\gltests\.libs\test-localename.exe 
(windows pid 8320)
    20      58 [main] test-localename (8320) OS version:   Windows NT-10.0
    15      73 [main] test-localename (8320) 
**********************************************
    66     139 [main] test-localename (8320) sigprocmask: 0 = 
sigprocmask (0, 0x0, 0x1802E4BB0)
   117     256 [main] test-localename 8320 child_copy: cygheap - hp 
0x154 low 0x180304408, high 0x18030FAB0, res 1
    19     275 [main] test-localename 8320 child_copy: done
    53     328 [main] test-localename 8320 open_shared: name shared.5, n 
5, shared 0x180030000 (wanted 0x180030000), h 0xB8, *m 6
    25     353 [main] test-localename 8320 user_heap_info::init: heap 
base 0x600000000, heap top 0x600000000, heap size 0x20000000 (536870912)
    20     373 [main] test-localename 8320 open_shared: name (null), n 
1, shared 0x180020000 (wanted 0x180020000), h 0xBC, *m 6
    17     390 [main] test-localename 8320 user_info::create: opening 
user shared for '' at 0x180020000
    16     406 [main] test-localename 8320 user_info::create: user 
shared version AB1FCCE8
    32     438 [main] test-localename (8320) open_shared: name (null), n 
11148, shared 0x180010000 (wanted 0x180010000), h 0x150, *m 6
    30     468 [main] test-localename 11148 pinfo::thisproc: myself 
dwProcessId 8320
    62     530 [main] test-localename 11148 time: 1483438254 = time(0x0)
   103     633 [main] test-localename 11148 open_shared: name 
cygpid.8320, n 8320, shared 0x20000 (wanted 0x0), h 0xC8, *m 5
    22     655 [main] test-localename 11148 
fhandler_pty_slave::fixup_after_fork: /dev/pty4 inherited, usecount 2
    19     674 [main] test-localename 11148 
fhandler_base::fixup_after_exec: here for 
'/cygdrive/d/misc/src/cygwin/libidn-1.33-1.x86_64/build/lib/gltests/LOG'
    19     693 [main] test-localename 11148 
fhandler_base::fixup_after_exec: here for 
'/cygdrive/d/misc/src/cygwin/libidn-1.33-1.x86_64/build/lib/gltests/LOG'
    18     711 [main] test-localename 11148 child_info::ready: signalled 
0x134 that I was ready
  2618   31577 [main] test-localename 11148! child_info::sync: pid 8320, 
WFMO returned 0, exit_code 0x103, res 1
    22   31599 [main] test-localename 11148! 
fhandler_base::close_with_arch: line 1140: /dev/pty4<0x18030C188> 
usecount + -1 = 1
    32     743 [main] test-localename 11148 fhandler_pipe::create: name 
\\.\pipe\cygwin-70dc0fd8e2b3a5e0-8320-sigwait, size 11440, mode 
PIPE_TYPE_MESSAGE
    16   31615 [main] test-localename 11148! 
fhandler_base::close_with_arch: not closing archetype
    13   31628 [main] test-localename 11148! fhandler_base::close: 
closing 
'/cygdrive/d/misc/src/cygwin/libidn-1.33-1.x86_64/build/lib/gltests/LOG' 
handle 0x258
    17   31645 [main] test-localename 11148! fhandler_base::close: 
closing 
'/cygdrive/d/misc/src/cygwin/libidn-1.33-1.x86_64/build/lib/gltests/LOG' 
handle 0x218
    18   31663 [main] test-localename 11148! proc_subproc: args: 1, 
-2145378112
    59     802 [main] test-localename 11148 fhandler_pipe::create: pipe 
read handle 0xDC
    21     823 [main] test-localename 11148 fhandler_pipe::create: 
CreateFile: name \\.\pipe\cygwin-70dc0fd8e2b3a5e0-8320-sigwait
--- Process 11148 thread 8740 created
    44     867 [main] test-localename 11148 fhandler_pipe::create: pipe 
write handle 0xE0
    26     893 [main] test-localename 11148 dll_crt0_0: finished 
dll_crt0_0 initialization
    93   31756 [main] test-localename 11148! pinfo::wait: created 
tracking thread for pid 11148, winpid 0x2080, rd_proc_pipe 0x160
    33   31789 [main] test-localename 11148! proc_subproc: added pid 
11148 to proc table, slot 0
    27   31816 [main] test-localename 11148! proc_subproc: returning 1
--- Process 8320 thread 8488 created
    75   31891 [waitproc] test-localename 11148! cygthread::stub: thread 
'waitproc', id 0x2224, stack_ptr 0xDBCCD0
   137    1030 [sig] test-localename 11148 wait_sig: entering ReadFile 
loop, my_readsig 0xDC, my_sendsig 0xE0
   145    1175 [main] test-localename 11148 sigprocmask: 0 = sigprocmask 
(0, 0x0, 0x600000150)
    78    1253 [main] test-localename 11148 _cygwin_istext_for_stdio: fd 
0: opened as binary
    17    1270 [main] test-localename 11148 _cygwin_istext_for_stdio: fd 
1: opened as binary
    14    1284 [main] test-localename 11148 _cygwin_istext_for_stdio: fd 
2: opened as binary
    65    1349 [main] test-localename 11148 parse_options: glob (called 
func)
    26    1375 [main] test-localename 11148 parse_options: returning
    14    1389 [main] test-localename 11148 pinfo_init: pid 11148, pgid 
10352, process_state 0xC1
    15    1404 [main] test-localename 11148 App version:  2006.1, api: 0.305
    15    1419 [main] test-localename 11148 DLL version:  2006.1, api: 0.305
    14    1433 [main] test-localename 11148 DLL build:    2016-12-16 11:55
    68    1501 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0409
   126    1627 [main] test-localename 11148 __set_errno: void 
dll_crt0_1(void*):979 setting errno 0
   183    1810 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0409
    37    1847 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0409
    49    1896 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0409
    58    1954 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0409
    48    2002 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0409
    60    2062 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0409
    97    2159 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
    68    2227 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
    67    2294 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
    67    2361 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
    71    2432 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
   231    2663 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
    36    2699 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
    35    2734 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
    36    2770 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
    35    2805 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
    90    2895 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
    46    2941 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
    46    2987 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
    82    3069 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
    55    3124 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
    51    3175 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
   106    3281 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0407
    53    3334 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0407
    62    3396 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0407
    57    3453 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0407
    48    3501 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0407
    81    3582 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x040C
    76    3658 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
    67    3725 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
    68    3793 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
    67    3860 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x0000
    76    3936 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x040C
    37    3973 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x040C
    47    4020 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x040C
    49    4069 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x040C
    58    4127 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x040C
    61    4188 [main] test-localename 11148 __get_lcid_from_locale: 
LCID=0x040C
/cygdrive/d/misc/src/cygwin/libidn-1.33-1.x86_64/src/libidn-1.33/lib/gltests/test-localename.c 
162    4350 [main] test-localename 11148 write: 94 = write(2, 
0x100406058, 94)
:   37    4387 [main] test-localename 11148 write: 1 = write(2, 
0x1004060B9, 1)
183   32    4419 [main] test-localename 11148 write: 3 = write(2, 
0xFFFFC9F1, 3)
: assertion '   30    4449 [main] test-localename 11148 write: 13 = 
write(2, 0x1004060BC, 13)
strcmp (name, "fr_FR.UTF-8") == 0   30    4479 [main] test-localename 
11148 write: 33 = write(2, 0x100406168, 33)
' failed
    30    4509 [main] test-localename 11148 write: 9 = write(2, 
0x1004060CB, 9)
    83    4592 [main] test-localename 11148 set_signal_mask: setmask 0, 
newmask FFFFFFFFFFFEFEDF, mask_bits 0
    16    4608 [main] test-localename 11148 kill0: kill (11148, 6)
    17    4625 [main] test-localename 11148 sig_send: sendsig 0xE0, pid 
11148, signal 6, its_me 1
    17    4642 [main] test-localename 11148 sig_send: wakeup 0x108
    18    4660 [main] test-localename 11148 sig_send: Waiting for 
pack.wakeup 0x108
    18    4678 [sig] test-localename 11148 sigpacket::process: signal 6 
processing
    20    4698 [sig] test-localename 11148 init_cygheap::find_tls: sig 6
    16    4714 [sig] test-localename 11148 sigpacket::process: using tls 
0xFFFFCE00
    39    4753 [sig] test-localename 11148 sigpacket::process: signal 6, 
signal handler 0x18005CD90
    15    4768 [sig] test-localename 11148 sigpacket::setup_handler: 
controlled interrupt. stackptr 0xFFFFE458, stack 0xFFFFE458, 
stackptr[-1] 0xFFFFE458
    19    4787 [sig] test-localename 11148 proc_subproc: args: 5, 1
    15    4802 [sig] test-localename 11148 proc_subproc: clear waiting 
threads
    15    4817 [sig] test-localename 11148 proc_subproc: finished clearing
    15    4832 [sig] test-localename 11148 proc_subproc: returning 1
    14    4846 [sig] test-localename 11148 _cygtls::interrupt_setup: 
armed signal_arrived 0x120, signal 6
    15    4861 [sig] test-localename 11148 sigpacket::setup_handler: 
signal 6 delivered
    15    4876 [sig] test-localename 11148 sigpacket::process: returning 1
    15    4891 [sig] test-localename 11148 wait_sig: signalling 
pack.wakeup 0x108
    18    4909 [main] test-localename 11148 set_process_mask_delta: 
oldmask FFFFFFFFFFFEFEDF, newmask FFFFFFFFFFFEFEDF, deltamask 0
    28    4937 [main] test-localename 11148 signal_exit: exiting due to 
signal 6
    5032 [main] test-localename 11148 
cygwin_exception::open_stackdumpfile: Dumping stack trace to 
test-localename.exe.stackdump
    95    5032 [main] test-localename 11148 
cygwin_exception::open_stackdumpfile: Dumping stack trace to 
test-localename.exe.stackdump
1199536 1204568 [main] test-localename 11148 signal_exit: about to call 
do_exit (86)
    84 1204652 [main] test-localename 11148 do_exit: do_exit (134), 
exit_state 2
...

The source code can be found in the file (after unpacking of 
https://ftp.gnu.org/gnu/libidn/libidn-1.33.tar.gz)

  o .../libidn-1.33-1.x86_64/src/libidn-1.33/lib/gltests/test-localename.c

My cygcheck output - http://volkerzell.de/cygwin/tmp/cygcheck-03.01.2017

Ciao
   Volker

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]

On Jan  3 11:53, Dr. Volker Zell wrote:
> On 29.12.2016 21:49, Yaakov Selkowitz wrote:
> > On 2016-09-30 01:43, Dr. Volker Zell wrote:
> > > > > > > > Yaakov Selkowitz writes:
> > > 
> > >     > Dr. Volker,
> > >     > Several security vulnerabilities have been announced for
> > > libidn, which are fixed
> > >     > in 1.33:
> > > 
> > >     >
> > > https://lists.gnu.org/archive/html/help-libidn/2016-07/msg00009.html
> > > 
> > > Noted (and also your other mails), will work on it as soon as real
> > > work permits.
> > 
> > Ping?
> > 
> 
> Hi
> 
> Just tried packaging libidn-1.33 and found a locale specific error in the
> test suite (Which was working fine with my latest build). When running under
> strace I get:
> [...]
> :   37    4387 [main] test-localename 11148 write: 1 = write(2, 0x1004060B9,
> 1)
> 183   32    4419 [main] test-localename 11148 write: 3 = write(2,
> 0xFFFFC9F1, 3)
> : assertion '   30    4449 [main] test-localename 11148 write: 13 = write(2,
> 0x1004060BC, 13)
> strcmp (name, "fr_FR.UTF-8") == 0   30    4479 [main] test-localename 11148
> write: 33 = write(2, 0x100406168, 33)
> ' failed
> [...]
> 
> The source code can be found in the file (after unpacking of
> https://ftp.gnu.org/gnu/libidn/libidn-1.33.tar.gz)
> 
>  o .../libidn-1.33-1.x86_64/src/libidn-1.33/lib/gltests/test-localename.c

Do you have a self-contained testcase, by any chance?


Thanks,
Corinna

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Dr. Volker Zell]

On 09.01.2017 15:26, Corinna Vinschen wrote:
> On Jan  3 11:53, Dr. Volker Zell wrote:
>> On 29.12.2016 21:49, Yaakov Selkowitz wrote:
>>> On 2016-09-30 01:43, Dr. Volker Zell wrote:
>>>>>>>>> Yaakov Selkowitz writes:
>>>>
>>>>     > Dr. Volker,
>>>>     > Several security vulnerabilities have been announced for
>>>> libidn, which are fixed
>>>>     > in 1.33:
>>>>
>>>>     >
>>>> https://lists.gnu.org/archive/html/help-libidn/2016-07/msg00009.html
>>>>
>>>> Noted (and also your other mails), will work on it as soon as real
>>>> work permits.
>>>
>>> Ping?
>>>
>>
>> Hi
>>
>> Just tried packaging libidn-1.33 and found a locale specific error in the
>> test suite (Which was working fine with my latest build). When running under
>> strace I get:
>> [...]
>> :   37    4387 [main] test-localename 11148 write: 1 = write(2, 0x1004060B9,
>> 1)
>> 183   32    4419 [main] test-localename 11148 write: 3 = write(2,
>> 0xFFFFC9F1, 3)
>> : assertion '   30    4449 [main] test-localename 11148 write: 13 = write(2,
>> 0x1004060BC, 13)
>> strcmp (name, "fr_FR.UTF-8") == 0   30    4479 [main] test-localename 11148
>> write: 33 = write(2, 0x100406168, 33)
>> ' failed
>> [...]
>>
>> The source code can be found in the file (after unpacking of
>> https://ftp.gnu.org/gnu/libidn/libidn-1.33.tar.gz)
>>
>>  o .../libidn-1.33-1.x86_64/src/libidn-1.33/lib/gltests/test-localename.c
>
> Do you have a self-contained testcase, by any chance?

No, just the testcase from the testsuite in libidn.

Ciao
   Volker

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

[Eric Blake]

[-- Attachment #1.1: Type: text/plain, Size: 673 bytes --]

On 01/18/2017 06:12 AM, Dr. Volker Zell wrote:

>>>
>>> The source code can be found in the file (after unpacking of
>>> https://ftp.gnu.org/gnu/libidn/libidn-1.33.tar.gz)
>>>
>>>  o
>>> .../libidn-1.33-1.x86_64/src/libidn-1.33/lib/gltests/test-localename.c
>>
>> Do you have a self-contained testcase, by any chance?
> 
> No, just the testcase from the testsuite in libidn.

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.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

On Jan 18 09:23, Eric Blake wrote:
> On 01/18/2017 06:12 AM, Dr. Volker Zell wrote:
> 
> >>>
> >>> The source code can be found in the file (after unpacking of
> >>> https://ftp.gnu.org/gnu/libidn/libidn-1.33.tar.gz)
> >>>
> >>>  o
> >>> .../libidn-1.33-1.x86_64/src/libidn-1.33/lib/gltests/test-localename.c
> >>
> >> Do you have a self-contained testcase, by any chance?
> > 
> > No, just the testcase from the testsuite in libidn.
> 
> 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.

Much appreciated.


Thanks,
Corinna

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Eric Blake]

[-- Attachment #1.1: Type: text/plain, Size: 1690 bytes --]

On 01/18/2017 09:23 AM, Eric Blake wrote:
> On 01/18/2017 06:12 AM, Dr. Volker Zell wrote:
> 
>>>>
>>>> The source code can be found in the file (after unpacking of
>>>> https://ftp.gnu.org/gnu/libidn/libidn-1.33.tar.gz)
>>>>
>>>>  o
>>>> .../libidn-1.33-1.x86_64/src/libidn-1.33/lib/gltests/test-localename.c
>>>
>>> Do you have a self-contained testcase, by any chance?
>>
>> No, just the testcase from the testsuite in libidn.
> 
> 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.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1875 bytes --]

On Jan 19 11:40, Eric Blake wrote:
> On 01/18/2017 09:23 AM, Eric Blake wrote:
> > On 01/18/2017 06:12 AM, Dr. Volker Zell wrote:
> > 
> >>>>
> >>>> The source code can be found in the file (after unpacking of
> >>>> https://ftp.gnu.org/gnu/libidn/libidn-1.33.tar.gz)
> >>>>
> >>>>  o
> >>>> .../libidn-1.33-1.x86_64/src/libidn-1.33/lib/gltests/test-localename.c
> >>>
> >>> Do you have a self-contained testcase, by any chance?
> >>
> >> No, just the testcase from the testsuite in libidn.
> > 
> > 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!

Corinna

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Eric Blake]

[-- Attachment #1.1: Type: text/plain, Size: 1882 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

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

[Eric Blake]

[-- Attachment #1.1: Type: text/plain, Size: 635 bytes --]

On 01/19/2017 12:19 PM, Corinna Vinschen wrote:
>> 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!

Proposed gnulib patch; can be applied to any project that uses gnulib
and wants to avoid the test-localename failure during 'make check'.

https://cygwin.com/ml/cygwin/2017-01/msg00259.html

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

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

[Yaakov Selkowitz]

On 2017-01-03 04:53, Dr. Volker Zell wrote:
> Just tried packaging libidn-1.33 and found a locale specific error in
> the test suite (Which was working fine with my latest build). When
> running under strace I get:

Dr. Volker,

Since the bug discovered by this test is unrelated to libidn itself, 
there should be no need to hold back the libidn release therefor.

-- 
Yaakov

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2281 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Eric Blake]

[-- Attachment #1.1: Type: text/plain, Size: 1478 bytes --]

On 01/19/2017 03:02 PM, Corinna Vinschen wrote:
>>>> 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.

>> 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?

Yes. Consider a library-writer that wants to do something in the correct
locale.  Here, you have a logical separation from the main app that
calls newlocale()/uselocale() and the library code that now wants to
reconstruct what the current locale is.  So being able to reconstruct
the names of the thread-local locale via gl_locale_name() makes the
library less coupled to the main app's setup.  In particular, at least
gettext wants to use it.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]

On Jan 19 15:17, Eric Blake wrote:
> On 01/19/2017 03:02 PM, Corinna Vinschen wrote:
> >>>> 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.
> 
> >> 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?
> 
> Yes. Consider a library-writer that wants to do something in the correct
> locale.  Here, you have a logical separation from the main app that
> calls newlocale()/uselocale() and the library code that now wants to
> reconstruct what the current locale is.  So being able to reconstruct
> the names of the thread-local locale via gl_locale_name() makes the
> library less coupled to the main app's setup.  In particular, at least
> gettext wants to use it.

Ok, makes sense.


Thanks,
Corinna

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Yaakov Selkowitz]

On 2017-01-19 14:42, Yaakov Selkowitz wrote:
> On 2017-01-03 04:53, Dr. Volker Zell wrote:
>> Just tried packaging libidn-1.33 and found a locale specific error in
>> the test suite (Which was working fine with my latest build). When
>> running under strace I get:
>
> Dr. Volker,
>
> Since the bug discovered by this test is unrelated to libidn itself,
> there should be no need to hold back the libidn release therefor.

Ping?

-- 
Yaakov

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

[Yaakov Selkowitz]

On 2017-02-22 12:58, Yaakov Selkowitz wrote:
> On 2017-01-19 14:42, Yaakov Selkowitz wrote:
>> On 2017-01-03 04:53, Dr. Volker Zell wrote:
>>> Just tried packaging libidn-1.33 and found a locale specific error in
>>> the test suite (Which was working fine with my latest build). When
>>> running under strace I get:
>>
>> Dr. Volker,
>>
>> Since the bug discovered by this test is unrelated to libidn itself,
>> there should be no need to hold back the libidn release therefor.
>
> Ping?

Ping 2?

-- 
Yaakov

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

[Yaakov Selkowitz]

On 2017-02-22 12:58, Yaakov Selkowitz wrote:
> On 2017-01-19 14:42, Yaakov Selkowitz wrote:
>> On 2017-01-03 04:53, Dr. Volker Zell wrote:
>>> Just tried packaging libidn-1.33 and found a locale specific error in
>>> the test suite (Which was working fine with my latest build). When
>>> running under strace I get:
>>
>> Dr. Volker,
>>
>> Since the bug discovered by this test is unrelated to libidn itself,
>> there should be no need to hold back the libidn release therefor.
>
> Ping?

Ping 2?

-- 
Yaakov

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

[Yaakov Selkowitz]

On 2017-03-10 16:01, Yaakov Selkowitz wrote:
> On 2017-02-22 12:58, Yaakov Selkowitz wrote:
>> On 2017-01-19 14:42, Yaakov Selkowitz wrote:
>>> On 2017-01-03 04:53, Dr. Volker Zell wrote:
>>>> Just tried packaging libidn-1.33 and found a locale specific error in
>>>> the test suite (Which was working fine with my latest build). When
>>>> running under strace I get:
>>>
>>> Dr. Volker,
>>>
>>> Since the bug discovered by this test is unrelated to libidn itself,
>>> there should be no need to hold back the libidn release therefor.
>>
>> Ping?
>
> Ping 2?

Ping 3?

-- 
Yaakov

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

[Yaakov Selkowitz]

On 2017-03-24 14:00, Yaakov Selkowitz wrote:
> On 2017-03-10 16:01, Yaakov Selkowitz wrote:
>> On 2017-02-22 12:58, Yaakov Selkowitz wrote:
>>> On 2017-01-19 14:42, Yaakov Selkowitz wrote:
>>>> On 2017-01-03 04:53, Dr. Volker Zell wrote:
>>>>> Just tried packaging libidn-1.33 and found a locale specific error in
>>>>> the test suite (Which was working fine with my latest build). When
>>>>> running under strace I get:
>>>>
>>>> Dr. Volker,
>>>>
>>>> Since the bug discovered by this test is unrelated to libidn itself,
>>>> there should be no need to hold back the libidn release therefor.
>>>
>>> Ping?
>>
>> Ping 2?
>
> Ping 3?

I have uploaded the latest version of libidn to fix these issues.

-- 
Yaakov