From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116778 invoked by alias); 19 Jan 2017 21:02:28 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 116605 invoked by uid 89); 19 Jan 2017 21:02:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-101.6 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*F:D*cygwin.com X-HELO: drew.franken.de Received: from mail-n.franken.de (HELO drew.franken.de) (193.175.24.27) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Jan 2017 21:02:24 +0000 Received: from aqua.hirmke.de (aquarius.franken.de [193.175.24.89]) (Authenticated sender: aquarius) by mail-n.franken.de (Postfix) with ESMTPSA id EBC88721E2822 for ; Thu, 19 Jan 2017 22:02:20 +0100 (CET) Received: from calimero.vinschen.de (calimero.vinschen.de [192.168.129.6]) by aqua.hirmke.de (Postfix) with ESMTP id 830275E03B4 for ; Thu, 19 Jan 2017 22:02:19 +0100 (CET) Received: by calimero.vinschen.de (Postfix, from userid 500) id 667F8A805FC; Thu, 19 Jan 2017 22:02:19 +0100 (CET) Date: Thu, 19 Jan 2017 21:02:00 -0000 From: Corinna Vinschen To: cygwin-apps@cygwin.com Subject: Re: [SECURITY] libidn - locale specific error in test suite Message-ID: <20170119210219.GA3775@calimero.vinschen.de> Reply-To: cygwin-apps@cygwin.com Mail-Followup-To: cygwin-apps@cygwin.com References: <90dee62a-dc34-f83a-7094-8e0df688d801@cygwin.com> <20381568-c93e-1517-0f3d-579a5e6ac3fa@volkerzell.de> <20170109142640.GC843@calimero.vinschen.de> <86acc3c1-23ff-d76c-f7c8-c3cefcd567fa@volkerzell.de> <39d8753c-c875-0910-8ce8-5464d09b8235@redhat.com> <20170119181930.GC25162@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-SW-Source: 2017-01/txt/msg00030.txt.bz2 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2256 On Jan 19 14:17, Eric Blake wrote: > On 01/19/2017 12:19 PM, Corinna Vinschen wrote: >=20 > >>> 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 gnul= ib > >> 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 upstre= am > >> release of that project that uses newer gnulib if it wants to work > >> around the bug. > >=20 > > Thanks for letting us know! >=20 > Actually, Cygwin (or newlib) will need a patch, too. glibc provides the > macro NL_LOCALE_NAME, which can be used as follows: >=20 > locale =3D newlocale(...); > uselocale(locale); > nl_langinfo_l(NL_LOCALE_NAME(LC_MESSAGES), locale); >=20 > to recover the name of the LC_MESSAGES portion of the locale object. >=20 > 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 --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --opJtzjQTFsWo+cga Content-Type: application/pgp-signature; name="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYgSlbAAoJEPU2Bp2uRE+gxvkP/06mlWCfghdcpAxk1d826z80 Pqi3vj6MhEkeyZAyBCUrCYNLb/JvyqAv6ULHnObruaD96s9XyOYHVSnr2B4iF0kv p0GypT4r8Srq0qadAg6cfoxOOIqJRThO0Yj7xySqxDwVc83wFYqvKCCFkqBj1KEN 3Guc0dGEqy/X5/tBeOPJZnJTAX7vbVoreIjWBSbwSLl9dzow21hmONCQXLKxAzyh 9EgUNT2OuRlZ+9GbwyMT279BMgjHiS74/iqYMYjLyHEVNaKf6JegbGLyDJYBJQPV 0/WHrYZHCaMa3aTxHw/20OiSdxF+tTAwDC+f78B4wB5ceOvtSD0MURxxNFZcNIha nyhH+e36EgzE80DDL13blJCtdr1lOw1DeamC6vwuPT9Ec8JBVZ7+Qx2v/xhRra/z DcLY7EQve64H55RHFKPwG2uWZQM/zTenRxZgy3VMxo41NBD3HAfbW3VANgXwGYpA gOpkYcWgGwVTRSikQEC90bHCFkzen9FrVAwdi1YeYBxc5krgxF6ttOYr2O7SV7P9 xwXXj5f7bdphEys8iGFiQF+zEKGw5v7GWSkbI4MCGOQ71Un8f6HaTUlHagAhstRn aQ1+957zzvRB4YES/+LWlvZf7CWrZOx0SAWJcb+VnyFjHgyg65zOEiYXJ8w/plu0 qzYnF9UnEg2vpkgGQMpo =BOyO -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga--