From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 25 16:22:16 2017 Received: (at 27809) by debbugs.gnu.org; 25 Jul 2017 20:22:16 +0000 Received: from localhost ([127.0.0.1]:56369 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1da6LJ-00007R-Sf for submit@debbugs.gnu.org; Tue, 25 Jul 2017 16:22:16 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:34705) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1da6LG-00007G-NZ for 27809@debbugs.gnu.org; Tue, 25 Jul 2017 16:22:07 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id F1E3520E80; Tue, 25 Jul 2017 16:22:05 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Tue, 25 Jul 2017 16:22:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=+SQGKhhe02xT0fac2RWeWsAsxlS4G9fEvgHG6ZdFW Bg=; b=HkwtayvXtwIXxIU45oyvElgyYYD8aRSq7XNCjyJzV/25NC2MrG4flJcxS 0tSJaFlv7zJgCg1ooUxt/o8axNuFoG3XP9JFfmtdMJf7bxvTENtjaIC9vJTgg/6u QHwPJf+coZ4583N0nL3oQq6HRxl4SKdV5I2Ob5ciFBYEyHRjnVHjIgznEb8CG7e/ Dl+xjv8V9EpX07GSUKNA/LYNgMJpqmK4iqu1IpCvk2EGH+pb9cpqTjX6GHjoGh+0 BtT6vAUlUqH6eCJXeT52r/cuoIEQDassEbs0RLqcE2iEb/FHlb+VDQBB+F89nf4M Yrj7iaaY0mOD2UGLckQLuQFKZ84rQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=+SQGKhhe02xT0fac2R WeWsAsxlS4G9fEvgHG6ZdFWBg=; b=d+Q6gizuSSfq69WjSiunSZ1raYfH+fx3Op PyOjsZAN/UTkZA7mqRYNZAvT+ZnPvtsnWp6F00MTGzMI7pKRwpax1LkdGyd8ar0y VWjJivMZ+zTiZffcQWIWZMji928w6fWYhSQkdz+nQ3ZWMXQOTdI0iKzijIYE9H86 /A2lz3FZ89V0Fbkcxb2qYxZtc6OKDY8miDpjGZlgSgMwUw3QhlRojuqoEMmJkkbK DxbFgsfVKTjN1cxfpA7WvozQHG1T9ZXtojIyvFDQrgKRPr7xwHQZnj4/w6fBzu5e S4z+/I/T6Ok+WcU1+vMrY1BfD8pOUSiM8Hwgt0YEwNTdW/SQejQw== X-ME-Sender: X-Sasl-enc: JJGDNrZbc80cbhWFtAl4/T96CZiTdx0/L6FNaW9b2F8G 1501014125 Received: from localhost (unknown [188.113.81.93]) by mail.messagingengine.com (Postfix) with ESMTPA id 828C07E1FC; Tue, 25 Jul 2017 16:22:05 -0400 (EDT) From: Marius Bakke To: Leo Famulari , 27809@debbugs.gnu.org Subject: Re: bug#27809: libidn2 underscore stripping problem In-Reply-To: <20170724195231.GA28842@jasmine.lan> References: <20170724195231.GA28842@jasmine.lan> User-Agent: Notmuch/0.24.2 (https://notmuchmail.org) Emacs/25.2.1 (x86_64-unknown-linux-gnu) Date: Tue, 25 Jul 2017 22:22:03 +0200 Message-ID: <87inigjmhg.fsf@fastmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27809 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --=-=-= Content-Type: text/plain Leo Famulari writes: > It was recently reported that libidn2 can cause issues for domains whose > names contain underscores, and maybe some other characters, too. It > matters to us because we build GnuTLS with libidn2. > > I'm not sure yet what the solution is for us. Help wanted! > > Original report: > https://github.com/systemd/systemd/issues/6426 > > libidn2 discussion: > https://gitlab.com/libidn/libidn2/issues/30 > > Upstream fix: > https://gitlab.com/libidn/libidn2/commit/a5cbc16efd02adb78d2d082b21c3ac4d3fa88d2e The commit refers to TR46 which is a Unicode standards document: http://unicode.org/reports/tr46/#STD3_Rules It appears the new IDNA processing rules disallow use of underscores in domain names, which is in direct conflict with e.g. RFC2782[0]. Part of the confusion comes from the fact that underscores are indeed disallowed in *hostnames* (as in A and AAAA records)[1]. So if libidn2 enforces STD3 compliance on *all* domain types (how can it distinguish?), that is not good. I'm not sure if it's worth grafting it until we have a real-world use case however. Though we could consider swallowing the ~2300 rebuilds in the next staging round for the new version which contains the fix. [0] https://tools.ietf.org/html/rfc2782 [1] https://tools.ietf.org/html/rfc1123#section-2 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAll3qGwACgkQoqBt8qM6 VPrqnQf/bHEkXs934ylvwVHnDv++34TGXcy1guig8ilOUmZ8byUIZRNrs2cMD4fi /Co4tUCJTfYpeLerQOdxsGGXcidpNrzOn9TJd932KbCVbxG8F6NgBGdOyj8YWK/q Mgh4gzY4M5d36PLj29bcOlaXPlnXdq2CaWQPLhNCdlo7nB9cVflcyvVX+E1Yhodu 3XNxtvNbhH1T8Fp1AIDwBZzkjsqNiURSyLZTznEBun8eVssLV3w3CWqAaAbiAMsn Z0lW0SrQHblaOvMLa77ZKrMkNvRaRTcdehizbAKo29d+PhijZ2nFazFtuGqwnw5N 569FifVjY41e2RDMpexXZQhC0fWYhg== =5Lli -----END PGP SIGNATURE----- --=-=-=--