From nmav at gnutls.org Fri Mar 3 15:35:17 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 3 Mar 2017 15:35:17 +0100 Subject: [gnutls-devel] session ticket key rotation In-Reply-To: References: <87fumvf7pq.fsf@alice.fifthhorseman.net> <87r36ecdo3.fsf@alice.fifthhorseman.net> <87fumtb783.fsf@alice.fifthhorseman.net> Message-ID: On Tue, Nov 15, 2016 at 8:26 AM, Nikos Mavrogiannopoulos wrote: >> Thanks for the thoughtful review! let me know if you have any other >> concerns or suggestions about the proposal. If you think it's in decent >> shape, should i open a gitlab ticket to track it? > Makes sense. Hi Daniel, I'm getting back of this because I find it quite interesting to have even if there is no immediate plan to implement it. Could you add a ticket describing your idea in the gitlab issue tracker? regards, Nikos From ametzler at bebt.de Sun Mar 5 16:20:24 2017 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 5 Mar 2017 16:20:24 +0100 Subject: [gnutls-devel] fixes on 3.3.x gnutls branch, why not this one? Message-ID: <20170305152024.n33u2t5biicttxpk@argenau.bebt.de> Hello, is there a reason why this patch was cherrypicked for the 3.5.x branch but not for 3.3.x? e2b02861caea3cb9a173e6993640b4e7112bdb44 pencdk: read_attribute: account buffer size That ensures that there is no read past the end of buffer. Resolves the oss-fuzz found bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=391 Relates: #159 tia, cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From n.mavrogiannopoulos at gmail.com Sun Mar 5 17:50:35 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sun, 05 Mar 2017 17:50:35 +0100 Subject: [gnutls-devel] fixes on 3.3.x gnutls branch, why not this one? In-Reply-To: <20170305152024.n33u2t5biicttxpk@argenau.bebt.de> References: <20170305152024.n33u2t5biicttxpk@argenau.bebt.de> Message-ID: <1488732635.5053.1.camel@gmail.com> On Sun, 2017-03-05 at 16:20 +0100, Andreas Metzler wrote: > Hello, > > is there a reason why this patch was cherrypicked for the 3.5.x > branch but not for 3.3.x? > e2b02861caea3cb9a173e6993640b4e7112bdb44 > pencdk: read_attribute: account buffer size > > That ensures that there is no read past the end of buffer. > > Resolves the oss-fuzz found bug: > https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=391 Hi, I didn't consider it severe enough to backport it. My understanding is that this is a read past the end of buffer, and cannot be exploited for a denial of service or otherwise. Let me know if I'm wrong. regards, Nikos From nmav at gnutls.org Mon Mar 6 08:04:30 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 06 Mar 2017 08:04:30 +0100 Subject: [gnutls-devel] gnutls 3.3.27 Message-ID: <1488783870.18801.1.camel@gnutls.org> Hello,? ?I've just released gnutls 3.3.27. This is a bug-fix release on the previous stable branch. * Version 3.3.27 (released 2017-03-06) ** libgnutls: read the pin-value attribute if the p11-kit version allows it. ** libgnutls: Addressed integer overflow resulting to invalid memory write ???in OpenPGP certificate parsing. Issue found using oss-fuzz project: ???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=420 [GNUTLS-SA-2017-3A] ** libgnutls: Addressed crashes in OpenPGP certificate parsing, related ???to private key parser. No longer allow OpenPGP certificates (public keys) ???to contain private key sub-packets. Issue found using oss-fuzz project: ???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=354 ???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=360 [GNUTLS-SA-2017-3B] ** libgnutls: Addressed large allocation in OpenPGP certificate parsing, that ???could lead in out-of-memory condition. Issue found using oss-fuzz project, ???and was fixed by Alex Gaynor: ???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=392 [GNUTLS-SA-2017-3C] ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from .??A list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.27.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.27.tar.xz.sig Note that it has been signed with my openpgp key: pub???3104R/96865171 2008-05-04 [expires: 2028-04-29] uid??????????????????Nikos Mavrogiannopoulos gnutls.org> uid??????????????????Nikos Mavrogiannopoulos gmail.com> sub???2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub???2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Mon Mar 6 08:05:39 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 06 Mar 2017 08:05:39 +0100 Subject: [gnutls-devel] gnutls 3.5.10 Message-ID: <1488783939.18801.2.camel@gnutls.org> Hello,? ?I've just released gnutls 3.5.10. This is a bug fix release on the 3.5.x branch. * Version 3.5.10 (released 2017-03-06) ** gnutls.pc: do not include libidn2 in Requires.private. The libidn2 versions ???available do not include libidn2.pc, thus the inclusion was causing pkg-config ???issues. Instead we include -lidn2 in Libs.private when compile against libidn2. ** libgnutls: optimized access to subject alternative names (SANs) in parsed ???certificates. The previous implementation assumed a small number of ???SANs in a certificate, with repeated calls to ASN.1 decoding of the extension ???without any intermediate caching. That caused delays in certificates with ???a long list of names in functions such as gnutls_x509_crt_check_hostname(). ???With the current code, the SANs are parsed once on certificate import. ???Resolves gitlab issue #165. ** libgnutls: Addressed integer overflow resulting to invalid memory write ???in OpenPGP certificate parsing. Issue found using oss-fuzz project: ???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=420 [GNUTLS-SA-2017-3A] ** libgnutls: Addressed read of 1 byte past the end of buffer in OpenPGP ???certificate parsing. Issue found using oss-fuzz project: ???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=391 ** libgnutls: Addressed crashes in OpenPGP certificate parsing, related ???to private key parser. No longer allow OpenPGP certificates (public keys) ???to contain private key sub-packets. Issue found using oss-fuzz project: ???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=354 ???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=360 [GNUTLS-SA-2017-3B] ** libgnutls: Addressed large allocation in OpenPGP certificate parsing, that ???could lead in out-of-memory condition. Issue found using oss-fuzz project, ???and was fixed by Alex Gaynor: ???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=392 [GNUTLS-SA-2017-3C] ** libgnutls: Print the key PIN value used by the HPKP protocol as per RFC7469 ???when printing certificate information. ** libgnutls: gnutls_ocsp_resp_verify_direct() and gnutls_ocsp_resp_verify() ???flags can be set from the gnutls_certificate_verify_flags enumeration. ???This allows the functions to pass the same flags available for certificates ???to the verification function (e.g., GNUTLS_VERIFY_DISABLE_TIME_CHECKS or ???GNUTLS_VERIFY_ALLOW_BROKEN). ** libgnutls: gnutls_store_commitment() can accept flag ???GNUTLS_SCOMMIT_FLAG_ALLOW_BROKEN. This is to allow the function to operate ???in applications which use SHA1 for example, after SHA1 is deprecated. ** certtool: No longer ignore the 'add_critical_extension' template option if ???the 'add_extension' option is not present. ** gnutls-cli: Added LMTP, POP3, NNTP, Sieve and PostgreSQL support to the ???starttls-proto command. Patch by Robert Scheck. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from .??A list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.10.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.10.tar.xz.sig Note that it has been signed with my openpgp key: pub???3104R/96865171 2008-05-04 [expires: 2028-04-29] uid??????????????????Nikos Mavrogiannopoulos gnutls.org> uid??????????????????Nikos Mavrogiannopoulos gmail.com> sub???2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub???2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From fgunbin at fastmail.fm Mon Mar 6 17:18:05 2017 From: fgunbin at fastmail.fm (Filipp Gunbin) Date: Mon, 06 Mar 2017 19:18:05 +0300 Subject: [gnutls-devel] gnutls 3.5.10 In-Reply-To: <1488783939.18801.2.camel@gnutls.org> (Nikos Mavrogiannopoulos's message of "Mon, 06 Mar 2017 08:05:39 +0100") References: <1488783939.18801.2.camel@gnutls.org> Message-ID: Thanks for the release! I've got problem building, it's something with guile. I have guile-2.0.14 built & installed. File guile/src/guile-gnutls-v-2.la is present. Thanks! Filipp ... GUILEC modules/gnutls.go Backtrace: In ice-9/eval.scm: 432: 19 [eval # #] In /usr/local/bin/guild: 72: 18 [main #] In srfi/srfi-1.scm: 616: 17 [for-each # #] In scripts/compile.scm: 190: 16 [# "modules/gnutls.scm"] In system/base/target.scm: 59: 15 [with-target "x86_64-apple-darwin16.4.0" ...] In system/base/compile.scm: 152: 14 [compile-file "modules/gnutls.scm" #:output-file ...] 43: 13 [call-once #] In ice-9/boot-9.scm: 174: 12 [with-throw-handler #t ...] In system/base/compile.scm: 59: 11 [#] 155: 10 [# #] 218: 9 [read-and-compile # #:from ...] 234: 8 [lp (# #) # ...] 182: 7 [lp (#) (eval-when # # ...) ...] In ice-9/boot-9.scm: 2412: 6 [save-module-excursion #] In language/scheme/compile-tree-il.scm: 31: 5 [#] In ice-9/psyntax.scm: 1107: 4 [expand-top-sequence ((eval-when # # #)) () ((top)) ...] 990: 3 [scan ((eval-when (expand load eval) (define %libdir #) ...)) () ...] 279: 2 [scan ((load-extension # "scm_init_gnutls")) () ((top)) ...] In unknown file: ?: 1 [load-extension "/Users/fgunbin/src/gnutls-3.5.10/guile/src/guile-gnutls-v-2" ...] In ice-9/boot-9.scm: 109: 0 [# misc-error ...] ice-9/boot-9.scm:109:20: In procedure #: ice-9/boot-9.scm:109:20: In procedure dynamic-link: file: "/Users/fgunbin/src/gnutls-3.5.10/guile/src/guile-gnutls-v-2", message: "file not found" make[3]: *** [modules/gnutls.go] Error 1 From tim.ruehsen at gmx.de Tue Mar 7 14:49:29 2017 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Tue, 07 Mar 2017 14:49:29 +0100 Subject: [gnutls-devel] https://lists.gnutls.org/, cert is only valid for lists.gnupg.org !? Message-ID: <7022315.zzbe0MQYVW@blitz-lx> Firefox reports: lists.gnutls.org uses an invalid security certificate. The certificate is only valid for lists.gnupg.org Error code: SSL_ERROR_BAD_CERT_DOMAIN Anything you can do about that ? Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From n.mavrogiannopoulos at gmail.com Tue Mar 7 19:22:02 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Tue, 7 Mar 2017 19:22:02 +0100 Subject: [gnutls-devel] lock-free random generator In-Reply-To: References: Message-ID: On Mon, Feb 27, 2017 at 12:00 PM, Nikos Mavrogiannopoulos wrote: > On Mon, Feb 20, 2017 at 8:14 AM, Nikos Mavrogiannopoulos > wrote: > >>> For the yarrow reseed logic, I think it may be preferable with a global instance. >> If we need yarrow, your recommendation seems to be the right approach. >> However, another thought it has been bugging me lately, is whether we >> need yarrow in gnutls. It looks quite suited for something central >> like /dev/urandom which has several maybe untrusted inputs, but for >> gnutls which seeds from /dev/urandom (or the equivalent system calls), >> having a PRNG which concerns itself with manipulation of input may not >> be adding the security it is perceived to add. > > And to answer myself, I do not think we need something complex as > yarrow in gnutls. Older systems may have needed it, but today we can > rely on /dev/urandom and getentropy() interfaces, and as such I no > longer it is necessary to bring that complexity to gnutls. > > I've redesigned the whole random generator and provided a high level > description at: > https://gitlab.com/gnutls/gnutls/blob/c6a01ff6c5a44a19b5f6dba9280da96cc28f92d8/doc/cha-crypto.texi#L111 > > The corresponding code is at: > https://gitlab.com/gnutls/gnutls/merge_requests/259 It is now merged in master [0]. In the process the gnutls PRNG got even more simplified and improved. regards, Nikos [0]. https://gitlab.com/gnutls/gnutls/merge_requests/259/diffs#20cb879c7f2aafd5e7d471c7fbb46f640f4a0149_519_524 From nmav at gnutls.org Wed Mar 8 08:43:16 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 8 Mar 2017 08:43:16 +0100 Subject: [gnutls-devel] https://lists.gnutls.org/, cert is only valid for lists.gnupg.org !? In-Reply-To: <7022315.zzbe0MQYVW@blitz-lx> References: <7022315.zzbe0MQYVW@blitz-lx> Message-ID: On Tue, Mar 7, 2017 at 2:49 PM, Tim Ruehsen wrote: > Firefox reports: > lists.gnutls.org uses an invalid security certificate. > The certificate is only valid for lists.gnupg.org > Error code: SSL_ERROR_BAD_CERT_DOMAIN > Anything you can do about that ? The lists.gnutls.org is a CNAME to lists.gnupg.org. Are there any direct links to https://lists.gnutls.org that we can replace? regards, Nikos From tim.ruehsen at gmx.de Thu Mar 9 11:23:20 2017 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Thu, 09 Mar 2017 11:23:20 +0100 Subject: [gnutls-devel] https://lists.gnutls.org/, cert is only valid for lists.gnupg.org !? In-Reply-To: References: <7022315.zzbe0MQYVW@blitz-lx> Message-ID: <62068104.C7L7QU3qND@blitz-lx> On Wednesday, March 8, 2017 8:43:16 AM CET Nikos Mavrogiannopoulos wrote: > On Tue, Mar 7, 2017 at 2:49 PM, Tim Ruehsen wrote: > > Firefox reports: > > lists.gnutls.org uses an invalid security certificate. > > The certificate is only valid for lists.gnupg.org > > Error code: SSL_ERROR_BAD_CERT_DOMAIN > > Anything you can do about that ? > > The lists.gnutls.org is a CNAME to lists.gnupg.org. Are there any > direct links to https://lists.gnutls.org that we can replace? These were among the hits when searching the net for GnuTLS and Must-Staple. The cert of lists.gnupg.org should include lists.gnutls.org, I guess. Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From tim.ruehsen at gmx.de Thu Mar 9 11:29:48 2017 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Thu, 09 Mar 2017 11:29:48 +0100 Subject: [gnutls-devel] https://lists.gnutls.org/, cert is only valid for lists.gnupg.org !? In-Reply-To: <62068104.C7L7QU3qND@blitz-lx> References: <7022315.zzbe0MQYVW@blitz-lx> <62068104.C7L7QU3qND@blitz-lx> Message-ID: <3629606.Z2NNBbIkax@blitz-lx> On Thursday, March 9, 2017 11:23:20 AM CET Tim Ruehsen wrote: > On Wednesday, March 8, 2017 8:43:16 AM CET Nikos Mavrogiannopoulos wrote: > > On Tue, Mar 7, 2017 at 2:49 PM, Tim Ruehsen wrote: > > > Firefox reports: > > > lists.gnutls.org uses an invalid security certificate. > > > The certificate is only valid for lists.gnupg.org > > > Error code: SSL_ERROR_BAD_CERT_DOMAIN > > > Anything you can do about that ? > > > > The lists.gnutls.org is a CNAME to lists.gnupg.org. Are there any > > direct links to https://lists.gnutls.org that we can replace? > > These were among the hits when searching the net for GnuTLS and Must-Staple. > > The cert of lists.gnupg.org should include lists.gnutls.org, I guess. Just as a side note... DuckDuckGo doesn't show hits for https://lists.gnutls.org, Google does. Google's indexing of pages with invalid certs is a bit odd, since the big browsers won't connect anyways. Just a waste of time for anyone not wanting 'exceptions'. Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From nmav at gnutls.org Thu Mar 9 15:03:12 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 9 Mar 2017 15:03:12 +0100 Subject: [gnutls-devel] https://lists.gnutls.org/, cert is only valid for lists.gnupg.org !? In-Reply-To: <62068104.C7L7QU3qND@blitz-lx> References: <7022315.zzbe0MQYVW@blitz-lx> <62068104.C7L7QU3qND@blitz-lx> Message-ID: On Thu, Mar 9, 2017 at 11:23 AM, Tim Ruehsen wrote: >> > Firefox reports: >> > lists.gnutls.org uses an invalid security certificate. >> > The certificate is only valid for lists.gnupg.org >> > Error code: SSL_ERROR_BAD_CERT_DOMAIN >> > Anything you can do about that ? >> >> The lists.gnutls.org is a CNAME to lists.gnupg.org. Are there any >> direct links to https://lists.gnutls.org that we can replace? > > These were among the hits when searching the net for GnuTLS and Must-Staple. > > The cert of lists.gnupg.org should include lists.gnutls.org, I guess. The setup of the web site certs is currently handled by Werner (in CC). I don't know if including lists.gnutls.org to the lists.gnupg.org certificate is possible. btw. for the same search I see lists.gnupg.org instead. regards, Nikos From wk at gnupg.org Fri Mar 10 10:40:26 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 10 Mar 2017 10:40:26 +0100 Subject: [gnutls-devel] https://lists.gnutls.org/, cert is only valid for lists.gnupg.org !? In-Reply-To: (Nikos Mavrogiannopoulos's message of "Thu, 9 Mar 2017 15:03:12 +0100") References: <7022315.zzbe0MQYVW@blitz-lx> <62068104.C7L7QU3qND@blitz-lx> Message-ID: <874lz1eagl.fsf@wheatstone.g10code.de> On Thu, 9 Mar 2017 15:03, nmav at gnutls.org said: > CC). I don't know if including lists.gnutls.org to the lists.gnupg.org > certificate is possible. Thanks to Letsencrypt.sh this is trivial. New cert is up. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nmav at gnutls.org Fri Mar 10 11:35:15 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 10 Mar 2017 11:35:15 +0100 Subject: [gnutls-devel] https://lists.gnutls.org/, cert is only valid for lists.gnupg.org !? In-Reply-To: <874lz1eagl.fsf@wheatstone.g10code.de> References: <7022315.zzbe0MQYVW@blitz-lx> <62068104.C7L7QU3qND@blitz-lx> <874lz1eagl.fsf@wheatstone.g10code.de> Message-ID: On Fri, Mar 10, 2017 at 10:40 AM, Werner Koch wrote: > On Thu, 9 Mar 2017 15:03, nmav at gnutls.org said: > >> CC). I don't know if including lists.gnutls.org to the lists.gnupg.org >> certificate is possible. > > Thanks to Letsencrypt.sh this is trivial. New cert is up. Thank you! From tim.ruehsen at gmx.de Fri Mar 10 13:16:35 2017 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Fri, 10 Mar 2017 13:16:35 +0100 Subject: [gnutls-devel] https://lists.gnutls.org/, cert is only valid for lists.gnupg.org !? In-Reply-To: <874lz1eagl.fsf@wheatstone.g10code.de> References: <7022315.zzbe0MQYVW@blitz-lx> <874lz1eagl.fsf@wheatstone.g10code.de> Message-ID: <2649819.qVe9pkJNa9@blitz-lx> On Friday, March 10, 2017 10:40:26 AM CET Werner Koch wrote: > On Thu, 9 Mar 2017 15:03, nmav at gnutls.org said: > > CC). I don't know if including lists.gnutls.org to the lists.gnupg.org > > certificate is possible. > > Thanks to Letsencrypt.sh this is trivial. New cert is up. Wow, that was fast. Thanks ! Regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From ametzler at bebt.de Sat Mar 11 15:34:59 2017 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 11 Mar 2017 15:34:59 +0100 Subject: [gnutls-devel] Debian bug #857436: libgnutls-openssl27: OpenSSL wrapper not exposing TLS 1.1/1.2 ciphers Message-ID: <20170311143459.4zsasws33l6s3flg@argenau.bebt.de> Hello, this is copy of http://bugs.debian.org/857436 by Justin Coffman reported against 3.5.10: 8X---------------------------------------------- Certain packages that rely on this OpenSSL wrapper library are unable to connect using TLS 1.1/1.2 cipher suites. Even though the server (and the client, when compiled against OpenSSL) supports the full array of TLS 1.1/1.2 ciphers, the package as provided seems to be limited to only TLS 1.0 ciphers. An example is bug #842120 in package tf5. tf5, when connecting using a version compiled manually against OpenSSL: % Connected to server using cipher ECDHE-RSA-AES128-GCM-SHA256. When connecting using the packaged version utilizing the OpenSSL wrapper: % Connected to server using cipher RSA_AES_128_CBC_SHA1. Given the progression toward the deprecation of TLS 1.0 (see NIST SP 800-52 Rev. 1), it would seem prudent to ensure that packages not written against GnuTLS are still capable of their full function. [...] 8X---------------------------------------------- I do not know but I suspect that the OpenSSL API has changed quite a bit in recent years and being a a good OpenSSL customer requires using these new APIs. e.g. from the Exim 4.89 announcement: "Please note that we are seeing OpenSSL issues which require 1.0.2 minimum ...". OTOH the GnuTLS openssl wrapper does not seem to be seeing active development. Therefore I suspect the usefulness of the GnuTLS openssl wrapper to be decreasing, since only programs with outdated OpenSSL code work. Am I guessing correctly? cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From nmav at gnutls.org Sun Mar 12 07:01:24 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 12 Mar 2017 07:01:24 +0100 Subject: [gnutls-devel] Debian bug #857436: libgnutls-openssl27: OpenSSL wrapper not exposing TLS 1.1/1.2 ciphers In-Reply-To: <20170311143459.4zsasws33l6s3flg@argenau.bebt.de> References: <20170311143459.4zsasws33l6s3flg@argenau.bebt.de> Message-ID: <1489298484.1972.1.camel@gnutls.org> On Sat, 2017-03-11 at 15:34 +0100, Andreas Metzler wrote: > Hello, > > this is copy of http://bugs.debian.org/857436 by Justin Coffman > reported > against 3.5.10: [...] > I do not know??but I suspect that the OpenSSL API has changed quite a > bit in recent years and being a a good OpenSSL customer requires > using > these new APIs. e.g. from the Exim 4.89 announcement: "Please note > that > we are seeing OpenSSL issues which require 1.0.2 minimum ...". > > OTOH the GnuTLS openssl wrapper does not seem to be seeing active > development. > > Therefore I suspect the usefulness of the GnuTLS openssl wrapper to > be decreasing, since only programs with outdated OpenSSL code work. > Am I guessing correctly? I guess so. Furthermore I have no plans updating this wrapper. If it proves no useful to existing programs, and there is no "owner" of it, I think it would make more sense to schedule dropping it from gnutls. regards, Nikos From alon.barlev at gmail.com Sun Mar 12 14:16:32 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 12 Mar 2017 15:16:32 +0200 Subject: [gnutls-devel] valgrind test openpgp-certs woodo Message-ID: Hi, I go this strange error in openpgp-certs and only in this test when running under valgrind. I could not find any reason for this so I describe what I do get. To make it short, after configure edit tests/cert-tests/Makefile and leave only openpgp-certs in TESTS. Then run make check, I experience the following valgrind error that fails the test: --- Checking OpenPGP certificate verification ==25840== Conditional jump or move depends on uninitialised value(s) ==25840== at 0x401A5D8: index (in /lib64/ld-2.23.so) ==25840== by 0x4007DEF: expand_dynamic_string_token (in /lib64/ld-2.23.so) ==25840== by 0x4007F84: fillin_rpath (in /lib64/ld-2.23.so) ==25840== by 0x400874B: _dl_init_paths (in /lib64/ld-2.23.so) ==25840== by 0x4002E21: dl_main (in /lib64/ld-2.23.so) ==25840== by 0x401820B: _dl_sysdep_start (in /lib64/ld-2.23.so) ==25840== by 0x4004EC8: _dl_start (in /lib64/ld-2.23.so) ==25840== by 0x4000CB7: ??? (in /lib64/ld-2.23.so) ==25840== by 0x7: ??? ==25840== by 0xFFEFFFAEA: ??? ==25840== by 0xFFEFFFB4B: ??? ==25840== by 0xFFEFFFB56: ??? ==25840== Failure: Connection to signed PGP certificate should have succeeded! (error code 15) FAIL openpgp-certs (exit status: 1) --- Interesting... if I run only the test using the following command it passes! $ rm openpgp-certs.log && make openpgp-certs.log I tried to compare the environment/usage and found nothing. I noticed the ss failures so prepared this[1] but errors to be harmless. Then found that the following does pass!!! PATH=$PATH:/usr/sbin:/sbin make check I tried to figure out where the problem comes from but could not... I thought you may have a better idea. Something in this specific test that uses the same utilities as any other similar tests is doing something special. Thanks, Alon [1] https://gitlab.com/gnutls/gnutls/merge_requests/300 From nmav at gnutls.org Mon Mar 13 08:04:20 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 13 Mar 2017 08:04:20 +0100 Subject: [gnutls-devel] valgrind test openpgp-certs woodo In-Reply-To: References: Message-ID: On Sun, Mar 12, 2017 at 2:16 PM, Alon Bar-Lev wrote: > Hi, > > I go this strange error in openpgp-certs and only in this test when > running under valgrind. I could not find any reason for this so I > describe what I do get. > > To make it short, after configure edit tests/cert-tests/Makefile and > leave only openpgp-certs in TESTS. > > Then run make check, I experience the following valgrind error that > fails the test: > --- > Checking OpenPGP certificate verification > ==25840== Conditional jump or move depends on uninitialised value(s) > ==25840== at 0x401A5D8: index (in /lib64/ld-2.23.so) > ==25840== by 0x4007DEF: expand_dynamic_string_token (in /lib64/ld-2.23.so) > ==25840== by 0x4007F84: fillin_rpath (in /lib64/ld-2.23.so) > ==25840== by 0x400874B: _dl_init_paths (in /lib64/ld-2.23.so) > ==25840== by 0x4002E21: dl_main (in /lib64/ld-2.23.so) > ==25840== by 0x401820B: _dl_sysdep_start (in /lib64/ld-2.23.so) > ==25840== by 0x4004EC8: _dl_start (in /lib64/ld-2.23.so) > ==25840== by 0x4000CB7: ??? (in /lib64/ld-2.23.so) > ==25840== by 0x7: ??? > ==25840== by 0xFFEFFFAEA: ??? > ==25840== by 0xFFEFFFB4B: ??? > ==25840== by 0xFFEFFFB56: ??? Hi, That looks like something happening even before gnutls is loaded. You may need debugging symbols in libc and dynamic loader to figure out. regards, Nikos From alon.barlev at gmail.com Mon Mar 13 11:46:10 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon, 13 Mar 2017 12:46:10 +0200 Subject: [gnutls-devel] valgrind test openpgp-certs woodo In-Reply-To: References: Message-ID: On 13 March 2017 at 09:04, Nikos Mavrogiannopoulos wrote: > Hi, > That looks like something happening even before gnutls is loaded. You > may need debugging symbols in libc and dynamic loader to figure out. Well, I kinda give up... but narrowed it to the following... if LD_LIBRARY_PATH contains absolute directory then it fails... libtool uses absolute path. In strace I could not find anything strange, it searches the shared libraries absolute or relative as expected. Many other tests that are expected to fail actually failed because of this a false positive... we do not check for the valgrind exit code explicitly. I found those[1][2][3] and more. Added this to suppression at [4] please consider. Thanks! Alon [1] http://stackoverflow.com/questions/11506370/valgrind-reports-unitialized-values-on-empty-c-program [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623876 [3] http://stackoverflow.com/questions/23663008/valgrind-reports-conditional-jump-or-move-depends-on-uninitialised-values-on [4] https://gitlab.com/gnutls/gnutls/merge_requests/304 --- $ LD_LIBRARY_PATH=$(cd ../../lib/.libs && pwd) valgrind -q --leak-check=full --suppressions=../../../gnutls-3.5.10/tests/cert-tests/suppressions.valgrind --error-exitcode=15 ../../src/.libs/gnutls-cli --help > /dev/null; echo $? ==32377== Conditional jump or move depends on uninitialised value(s) ==32377== at 0x401A5D8: index (in /lib64/ld-2.23.so) ==32377== by 0x4007DEF: expand_dynamic_string_token (in /lib64/ld-2.23.so) ==32377== by 0x4007F84: fillin_rpath (in /lib64/ld-2.23.so) ==32377== by 0x400874B: _dl_init_paths (in /lib64/ld-2.23.so) ==32377== by 0x4002E21: dl_main (in /lib64/ld-2.23.so) ==32377== by 0x401820B: _dl_sysdep_start (in /lib64/ld-2.23.so) ==32377== by 0x4004EC8: _dl_start (in /lib64/ld-2.23.so) ==32377== by 0x4000CB7: ??? (in /lib64/ld-2.23.so) ==32377== by 0x1: ??? ==32377== by 0xFFEFFFE1E: ??? ==32377== by 0xFFEFFFE39: ??? ==32377== 15 $ LD_LIBRARY_PATH=../../lib/.libs valgrind -q --leak-check=full --suppressions=../../../gnutls-3.5.10/tests/cert-tests/suppressions.valgrind --error-exitcode=15 ../../src/.libs/gnutls-cli --help > /dev/null; echo $? 0 --- From alon.barlev at gmail.com Mon Mar 13 18:49:02 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon, 13 Mar 2017 19:49:02 +0200 Subject: [gnutls-devel] valgrind-tests vs full-test-suite Message-ID: Hi, I believe this is the last issue in tests of gnutls-3.5... :) I started stabilization process in Gentoo, it will be nice if we can solve this nicely as well. Look at this full-test-suite[1] conditional: --- # test if we are in git master or in release build. In release # builds we do not use valgrind. SUITE_FILE="${srcdir}/tests/suite/mini-eagain2.c" if test "$full_test_suite" = yes && test ! -f "$SUITE_FILE";then full_test_suite=no VALGRIND="" AC_SUBST(VALGRIND, []) opt_valgrind_tests=no fi --- This actually disables valgrind in non-git but I do not see any reason to do so as valgrind is supported in some other tests. If I disable the full-tests-suite then I can enjoy valgrind extra tests. Any reason why we condition this? Thanks! Alon [1] https://gitlab.com/gnutls/gnutls/blob/master/configure.ac#L360 From dkg at fifthhorseman.net Tue Mar 14 05:46:36 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 14 Mar 2017 00:46:36 -0400 Subject: [gnutls-devel] session ticket key rotation In-Reply-To: References: <87fumvf7pq.fsf@alice.fifthhorseman.net> <87r36ecdo3.fsf@alice.fifthhorseman.net> <87fumtb783.fsf@alice.fifthhorseman.net> Message-ID: <87pohksbwz.fsf@alice.fifthhorseman.net> On Fri 2017-03-03 09:35:17 -0500, Nikos Mavrogiannopoulos wrote: > On Tue, Nov 15, 2016 at 8:26 AM, Nikos Mavrogiannopoulos > wrote: >>> Thanks for the thoughtful review! let me know if you have any other >>> concerns or suggestions about the proposal. If you think it's in decent >>> shape, should i open a gitlab ticket to track it? >> Makes sense. > > Hi Daniel, > I'm getting back of this because I find it quite interesting to have > even if there is no immediate plan to implement it. Could you add a > ticket describing your idea in the gitlab issue tracker? i've just opened https://gitlab.com/gnutls/gnutls/issues/184 sorry that i don't have any patches to offer yet! thanks, --dkg From nmav at gnutls.org Tue Mar 14 08:36:58 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 14 Mar 2017 08:36:58 +0100 Subject: [gnutls-devel] valgrind-tests vs full-test-suite In-Reply-To: References: Message-ID: On Mon, Mar 13, 2017 at 6:49 PM, Alon Bar-Lev wrote: > Hi, > > I believe this is the last issue in tests of gnutls-3.5... :) > > I started stabilization process in Gentoo, it will be nice if we can > solve this nicely as well. > > Look at this full-test-suite[1] conditional: > --- > # test if we are in git master or in release build. In release > # builds we do not use valgrind. > SUITE_FILE="${srcdir}/tests/suite/mini-eagain2.c" > if test "$full_test_suite" = yes && test ! -f "$SUITE_FILE";then > full_test_suite=no > VALGRIND="" > AC_SUBST(VALGRIND, []) > opt_valgrind_tests=no > fi > --- > > This actually disables valgrind in non-git but I do not see any reason > to do so as valgrind is supported in some other tests. If I disable > the full-tests-suite then I can enjoy valgrind extra tests. > Any reason why we condition this? If I remember well, the reason this was introduced was to avoid test suite failures due to leaks or other issues in unrelated libraries on the released version. E.g., if you try to compile the latest release of gnutls in a system which has a libc with a leak, you wouldn't have the test suite fail because of that. regards, Nikos From alon.barlev at gmail.com Tue Mar 14 08:41:35 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 14 Mar 2017 09:41:35 +0200 Subject: [gnutls-devel] valgrind-tests vs full-test-suite In-Reply-To: References: Message-ID: On 14 March 2017 at 09:36, Nikos Mavrogiannopoulos wrote: > On Mon, Mar 13, 2017 at 6:49 PM, Alon Bar-Lev wrote: >> Hi, >> >> I believe this is the last issue in tests of gnutls-3.5... :) >> >> I started stabilization process in Gentoo, it will be nice if we can >> solve this nicely as well. >> >> Look at this full-test-suite[1] conditional: >> --- >> # test if we are in git master or in release build. In release >> # builds we do not use valgrind. >> SUITE_FILE="${srcdir}/tests/suite/mini-eagain2.c" >> if test "$full_test_suite" = yes && test ! -f "$SUITE_FILE";then >> full_test_suite=no >> VALGRIND="" >> AC_SUBST(VALGRIND, []) >> opt_valgrind_tests=no >> fi >> --- >> >> This actually disables valgrind in non-git but I do not see any reason >> to do so as valgrind is supported in some other tests. If I disable >> the full-tests-suite then I can enjoy valgrind extra tests. >> Any reason why we condition this? > > If I remember well, the reason this was introduced was to avoid test > suite failures due to leaks or other issues in unrelated libraries on > the released version. E.g., if you try to compile the latest release > of gnutls in a system which has a libc with a leak, you wouldn't have > the test suite fail because of that. The valgrind tests may be enabled or disabled. In release tarball there is no full-suite. The result is that valgrind cannot be enabled unless the non-existence full-suite is disabled... So I do not think this logic is required. From nmav at gnutls.org Tue Mar 14 13:41:01 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 14 Mar 2017 13:41:01 +0100 Subject: [gnutls-devel] valgrind-tests vs full-test-suite In-Reply-To: References: Message-ID: On Tue, Mar 14, 2017 at 8:41 AM, Alon Bar-Lev wrote: >>> This actually disables valgrind in non-git but I do not see any reason >>> to do so as valgrind is supported in some other tests. If I disable >>> the full-tests-suite then I can enjoy valgrind extra tests. >>> Any reason why we condition this? >> >> If I remember well, the reason this was introduced was to avoid test >> suite failures due to leaks or other issues in unrelated libraries on >> the released version. E.g., if you try to compile the latest release >> of gnutls in a system which has a libc with a leak, you wouldn't have >> the test suite fail because of that. > > The valgrind tests may be enabled or disabled. That's true but we have them enabled by default, so builds would fail for that reason and that would create more noise in the list. > In release tarball there is no full-suite. > The result is that valgrind cannot be enabled unless the non-existence > full-suite is disabled... > So I do not think this logic is required. That's true, but I am afraid of the issue above (when this was added was specifically to avoid such reports from the list). It should be combined with another change that makes valgrind not to run by default on releases. regards, Nikos From alon.barlev at gmail.com Tue Mar 14 14:01:05 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 14 Mar 2017 15:01:05 +0200 Subject: [gnutls-devel] valgrind-tests vs full-test-suite In-Reply-To: References: Message-ID: On 14 March 2017 at 14:41, Nikos Mavrogiannopoulos wrote: > > On Tue, Mar 14, 2017 at 8:41 AM, Alon Bar-Lev wrote: > > >>> This actually disables valgrind in non-git but I do not see any reason > >>> to do so as valgrind is supported in some other tests. If I disable > >>> the full-tests-suite then I can enjoy valgrind extra tests. > >>> Any reason why we condition this? > >> > >> If I remember well, the reason this was introduced was to avoid test > >> suite failures due to leaks or other issues in unrelated libraries on > >> the released version. E.g., if you try to compile the latest release > >> of gnutls in a system which has a libc with a leak, you wouldn't have > >> the test suite fail because of that. > > > > The valgrind tests may be enabled or disabled. > > That's true but we have them enabled by default, so builds would fail > for that reason and that would create more noise in the list. > > > In release tarball there is no full-suite. > > The result is that valgrind cannot be enabled unless the non-existence > > full-suite is disabled... > > So I do not think this logic is required. > > That's true, but I am afraid of the issue above (when this was added > was specifically to avoid such reports from the list). It should be > combined with another change that makes valgrind not to run by default > on releases. Hi, Can we disable this by default and enable it explicitly in all ci jobs? Or can we add another flag that is disabled by default and when enabled will not touch the VALGRIND? Alon From alon.barlev at gmail.com Tue Mar 14 14:09:55 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 14 Mar 2017 15:09:55 +0200 Subject: [gnutls-devel] valgrind-tests vs full-test-suite In-Reply-To: References: Message-ID: On 14 March 2017 at 15:01, Alon Bar-Lev wrote: > On 14 March 2017 at 14:41, Nikos Mavrogiannopoulos wrote: >> >> On Tue, Mar 14, 2017 at 8:41 AM, Alon Bar-Lev wrote: >> >> >>> This actually disables valgrind in non-git but I do not see any reason >> >>> to do so as valgrind is supported in some other tests. If I disable >> >>> the full-tests-suite then I can enjoy valgrind extra tests. >> >>> Any reason why we condition this? >> >> >> >> If I remember well, the reason this was introduced was to avoid test >> >> suite failures due to leaks or other issues in unrelated libraries on >> >> the released version. E.g., if you try to compile the latest release >> >> of gnutls in a system which has a libc with a leak, you wouldn't have >> >> the test suite fail because of that. >> > >> > The valgrind tests may be enabled or disabled. >> >> That's true but we have them enabled by default, so builds would fail >> for that reason and that would create more noise in the list. >> >> > In release tarball there is no full-suite. >> > The result is that valgrind cannot be enabled unless the non-existence >> > full-suite is disabled... >> > So I do not think this logic is required. >> >> That's true, but I am afraid of the issue above (when this was added >> was specifically to avoid such reports from the list). It should be >> combined with another change that makes valgrind not to run by default >> on releases. > > Hi, > Can we disable this by default and enable it explicitly in all ci jobs? > Or can we add another flag that is disabled by default and when > enabled will not touch the VALGRIND? > Alon I can disable these by default if it is a release tarball (no full-test-suite), maybe this is the best. From nmav at gnutls.org Tue Mar 14 14:34:58 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 14 Mar 2017 14:34:58 +0100 Subject: [gnutls-devel] valgrind-tests vs full-test-suite In-Reply-To: References: Message-ID: On Tue, Mar 14, 2017 at 2:01 PM, Alon Bar-Lev wrote: >> That's true but we have them enabled by default, so builds would fail >> for that reason and that would create more noise in the list. >> >> > In release tarball there is no full-suite. >> > The result is that valgrind cannot be enabled unless the non-existence >> > full-suite is disabled... >> > So I do not think this logic is required. >> >> That's true, but I am afraid of the issue above (when this was added >> was specifically to avoid such reports from the list). It should be >> combined with another change that makes valgrind not to run by default >> on releases. > Can we disable this by default and enable it explicitly in all ci jobs? > Or can we add another flag that is disabled by default and when > enabled will not touch the VALGRIND? Makes sense. From alon.barlev at gmail.com Tue Mar 14 21:27:45 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 14 Mar 2017 22:27:45 +0200 Subject: [gnutls-devel] valgrind-tests vs full-test-suite In-Reply-To: References: Message-ID: On 14 March 2017 at 15:34, Nikos Mavrogiannopoulos wrote: > On Tue, Mar 14, 2017 at 2:01 PM, Alon Bar-Lev wrote: >>> That's true but we have them enabled by default, so builds would fail >>> for that reason and that would create more noise in the list. >>> >>> > In release tarball there is no full-suite. >>> > The result is that valgrind cannot be enabled unless the non-existence >>> > full-suite is disabled... >>> > So I do not think this logic is required. >>> >>> That's true, but I am afraid of the issue above (when this was added >>> was specifically to avoid such reports from the list). It should be >>> combined with another change that makes valgrind not to run by default >>> on releases. > >> Can we disable this by default and enable it explicitly in all ci jobs? >> Or can we add another flag that is disabled by default and when >> enabled will not touch the VALGRIND? > > Makes sense. Hmmm... I probably did not understand what option "Makes sense" :) So I've done the first...[1], please checkout. I found that much more CI jobs explicitly disables valgrind anyway... so it actually makes everything simpler. I can do the second if you do not like this one. [1] https://gitlab.com/gnutls/gnutls/merge_requests/309 From nmav at gnutls.org Wed Mar 15 05:42:43 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 15 Mar 2017 05:42:43 +0100 Subject: [gnutls-devel] valgrind-tests vs full-test-suite In-Reply-To: References: Message-ID: <1489552963.5051.2.camel@gnutls.org> On Tue, 2017-03-14 at 22:27 +0200, Alon Bar-Lev wrote: > On 14 March 2017 at 15:34, Nikos Mavrogiannopoulos > wrote: > > On Tue, Mar 14, 2017 at 2:01 PM, Alon Bar-Lev > m> wrote: > > > > That's true but we have them enabled by default, so builds > > > > would fail > > > > for that reason and that would create more noise in the list. > > > > > > > > > In release tarball there is no full-suite. > > > > > The result is that valgrind cannot be enabled unless the non- > > > > > existence > > > > > full-suite is disabled... > > > > > So I do not think this logic is required. > > > > > > > > That's true, but I am afraid of the issue above (when this was > > > > added > > > > was specifically to avoid such reports from the list). It > > > > should be > > > > combined with another change that makes valgrind not to run by > > > > default > > > > on releases. > > > Can we disable this by default and enable it explicitly in all ci > > > jobs? > > > Or can we add another flag that is disabled by default and when > > > enabled will not touch the VALGRIND? > > > > Makes sense. > > Hmmm... I probably did not understand what option "Makes sense" :) Sorry, I meant the first one: "Can we disable this by default and enable it explicitly in all ci jobs?" > So I've done the first...[1], please checkout. Thanks, commented on the MR. regards, Nikos From n.mavrogiannopoulos at gmail.com Wed Mar 15 13:52:27 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Wed, 15 Mar 2017 13:52:27 +0100 Subject: [gnutls-devel] GnuTLS hostname checking bug report In-Reply-To: References: Message-ID: On Tue, Mar 14, 2017 at 7:12 PM, Suphannee Sivakorn wrote: > Dear Sir/Madam, > > We are a team of security researchers from Columbia University. As > part of recent research on SSL/TLS hostname verification, we have > audited your implementation (GnuTLS 3.5.3) and found 4 behaviors that > differ from other libraries' implementations. Below we provide > information from our experiments and findings. Please feel free to > contact us for more information. Hello and thank you for your work in identifying these interesting cases. > 1. Attempting to match CN when any SubjectAltName identifiers present (RFC 6125) > Section 6.3 of RFC 6125 prohibits clients from attempting to match CN > if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any > application-specific identifier types supported by the client. We > found that GnuTLS violates this requirement. The function > gnutls_x509_crt_check_hostname(2), which supports hostname > verification for hostname and IP address, attempts to match > certificate CN even when there is a subjectAltName identifier > presents, e.g., IP address. However, the library follows the > requirement when subjectAltName DNS presents. That is quite interesting. The actual text of RFC6125 is: "Security Warning: A client MUST NOT seek a match for a reference identifier of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client." My understanding of the text is that, the last part of the sentence implies that the prohibition of falling back to CN-ID matching applies when SRV-ID and URI-ID are supported. Given that gnutls doesn't support SRV-ID or URI-ID matching, it falls back immediately after the DNS-ID is checked. I may be wrong though, and I'm forwarding your message to the gnutls development list for further discussion. > 2. Matching wildcard with empty label > We found that GnuTLS matches with empty label, e.g., matches hostname > ".aaa.aaa" with certificate commonName(CN)/subjectAltName DNS: > "*.aaa.aaa". However, the .aaa.aaa is not valid domain name according > to RFC 1034 which requires each label must be between 1 to 63 > characters long, except the root label. That is a nice observation. However, since '.aaa.aaa' is already an illegal hostname addressing this would mean gnutls checking the application input for having valid DNS format. I am not sure if we should go into large extends of verifying application input (e.g., we also do not check whether the label length is over 63 characters), unless you believe there are security implications in that; in that case I'd appreciate if you could expand. > 3. No hostname validation > The library attempts to match the provided hostname even when the > certificate's CN/DNS or the hostname contains one, or more, invalid > characters. In the context of DNS names, invalid characters are all > characters outside the range [A-Za-z0-9.-]. For example GnuTLS allows > wildcard character to be interpreted as a literal character in the > name check verification. For example, the library will match hostname > "example.*.com" with certificate CN/DNS "example.*.com", even though > the wildcard character "*" is not in the valid character set for > domain names. An additional example would be matching hostname > "example.a=.com" with certificate CN/DNS "example.a=.com". That is related but not identical to the above point. The input to the hostname validation function is expected to be a valid hostname. If it is not, indeed undefined results can happen. Said that, you got a point that having a sanity check on the stored in the certificate DNS names is a good thing. I believe that's already the case in GnuTLS version 3.5.9. That version introduced IDNA2008 support and it performs extensive checks for valid format of DNS names stored in certificates. > Ensuring > that CN/DNS with invalid characters are rejected, will make the > library more robust against attacks that utilize such characters such > as the NULL byte injection attacks. I believe NULL byte injection attacks are explicitly countered. > 4. Matching IPv4 string hostname with subjectAltName DNS > We found that giving IPv4 format string as hostname, GnuTLS attempts > to match this string with DNS attribute in the certificate > subjectAltName when IP address attribute in the certificate > subjectAltName does not match or present. Since RFC 1123 allows the > domain name to be letter or digit, this introduced valid DNS names > which are identical to IP addresses. That is an unfortunate but documented behavior for certain broken situations. See: http://www.gnutls.org/manual/html_node/X509-certificate-API.html#index-gnutls_005fx509_005fcrt_005fcheck_005fhostname2 It used to be that the DNS field contained IP addresses in some big PKI deployments. I'd appreciate if you could share your findings on other implementations for that issue, as it would help us decide whether to deprecate that behavior. > The first observation we make is that the set of valid domain names is > a superset of the set of valid IP addresses. Let assume that attacker > targets SSL/TLS connections to the server with IP address > 85.130.200.4. The IP address 85.130.200.4 can be considered as a > subdomain of the top level domain 200.4. One may point out that .4 is, > currently, not a valid top level domain. However new top level domains > are being added frequently upon request. Since there is no fundamental > restriction in the format of a top level domain, it is completely > within the realm of possibility that purely arithmetic top level > domains will appear in the near future. To perform the attack, the > attacker is generating a certificate for the subdomain of 200.4 [...] That is certainly a concern. regards, Nikos From n.mavrogiannopoulos at gmail.com Thu Mar 16 11:48:59 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Thu, 16 Mar 2017 11:48:59 +0100 Subject: [gnutls-devel] Fwd: GnuTLS hostname checking bug report In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Suphannee Sivakorn Date: Thu, Mar 16, 2017 at 5:56 AM Subject: Re: GnuTLS hostname checking bug report To: Nikos Mavrogiannopoulos Cc: "George Argyros (Columbia University" , Kexin Pei , Suman Jana , GnuTLS development list Hi Nikos, thank you for your quick reply! Please see below and feel free to let us know for any further information. Thanks, Suphannee On Wed, Mar 15, 2017 at 8:52 AM, Nikos Mavrogiannopoulos wrote: > On Tue, Mar 14, 2017 at 7:12 PM, Suphannee Sivakorn > wrote: >> Dear Sir/Madam, >> >> We are a team of security researchers from Columbia University. As >> part of recent research on SSL/TLS hostname verification, we have >> audited your implementation (GnuTLS 3.5.3) and found 4 behaviors that >> differ from other libraries' implementations. Below we provide >> information from our experiments and findings. Please feel free to >> contact us for more information. > > Hello and thank you for your work in identifying these interesting cases. > >> 1. Attempting to match CN when any SubjectAltName identifiers present (RFC 6125) >> Section 6.3 of RFC 6125 prohibits clients from attempting to match CN >> if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any >> application-specific identifier types supported by the client. We >> found that GnuTLS violates this requirement. The function >> gnutls_x509_crt_check_hostname(2), which supports hostname >> verification for hostname and IP address, attempts to match >> certificate CN even when there is a subjectAltName identifier >> presents, e.g., IP address. However, the library follows the >> requirement when subjectAltName DNS presents. > > That is quite interesting. The actual text of RFC6125 is: > "Security Warning: A client MUST NOT seek a match for a reference > identifier of CN-ID if the presented identifiers include a DNS-ID, > SRV-ID, URI-ID, or any application-specific identifier types > supported by the client." > > My understanding of the text is that, the last part of the sentence > implies that the prohibition of falling back to CN-ID matching applies > when SRV-ID and URI-ID are supported. Given that gnutls doesn't > support SRV-ID or URI-ID matching, it falls back immediately after the > DNS-ID is checked. I may be wrong though, and I'm forwarding your > message to the gnutls development list for further discussion. > #1. The actual text also includes "or any application-specific identifier types". As the function gnutls_x509_crt_check_hostname() also supports IP address identifier, we believe that if IP-address/DNS in SubjectAltName presents, the check for CN should be skipped. We also agree that this is very unclear from RFC. After testing with many implementations, some of them do follow it (e.g., CPython SSL, cURL), and some of them not (e.g., MatrixSSL, JSSE). >> 2. Matching wildcard with empty label >> We found that GnuTLS matches with empty label, e.g., matches hostname >> ".aaa.aaa" with certificate commonName(CN)/subjectAltName DNS: >> "*.aaa.aaa". However, the .aaa.aaa is not valid domain name according >> to RFC 1034 which requires each label must be between 1 to 63 >> characters long, except the root label. > > That is a nice observation. However, since '.aaa.aaa' is already an > illegal hostname addressing this would mean gnutls checking the > application input for having valid DNS format. I am not sure if we > should go into large extends of verifying application input (e.g., we > also do not check whether the label length is over 63 characters), > unless you believe there are security implications in that; in that > case I'd appreciate if you could expand. #2. We agree that RFC 6125 nor 5280 does not specify the correct behavior for matching empty label on wildcard certificate. Undoubtedly this creates discrepancies. Since the RFC doesn't say, it is not a violation and therefore up to developer to decide. Unfortunately we haven't found any exploitable for this case too. We are trying to let developers know about it. > >> 3. No hostname validation >> The library attempts to match the provided hostname even when the >> certificate's CN/DNS or the hostname contains one, or more, invalid >> characters. In the context of DNS names, invalid characters are all >> characters outside the range [A-Za-z0-9.-]. For example GnuTLS allows >> wildcard character to be interpreted as a literal character in the >> name check verification. For example, the library will match hostname >> "example.*.com" with certificate CN/DNS "example.*.com", even though >> the wildcard character "*" is not in the valid character set for >> domain names. An additional example would be matching hostname >> "example.a=.com" with certificate CN/DNS "example.a=.com". > > That is related but not identical to the above point. The input to the > hostname validation function is expected to be a valid hostname. If it > is not, indeed undefined results can happen. Said that, you got a > point that having a sanity check on the stored in the certificate DNS > names is a good thing. I believe that's already the case in GnuTLS > version 3.5.9. That version introduced IDNA2008 support and it > performs extensive checks for valid format of DNS names stored in > certificates. > #3. That sounds good. We haven't test that version yet. We will report again when we retest with that expensive check. >> Ensuring >> that CN/DNS with invalid characters are rejected, will make the >> library more robust against attacks that utilize such characters such >> as the NULL byte injection attacks. > > I believe NULL byte injection attacks are explicitly countered. > >> 4. Matching IPv4 string hostname with subjectAltName DNS >> We found that giving IPv4 format string as hostname, GnuTLS attempts >> to match this string with DNS attribute in the certificate >> subjectAltName when IP address attribute in the certificate >> subjectAltName does not match or present. Since RFC 1123 allows the >> domain name to be letter or digit, this introduced valid DNS names >> which are identical to IP addresses. > > That is an unfortunate but documented behavior for certain broken > situations. See: > http://www.gnutls.org/manual/html_node/X509-certificate-API.html#index-gnutls_005fx509_005fcrt_005fcheck_005fhostname2 > > It used to be that the DNS field contained IP addresses in some big > PKI deployments. I'd appreciate if you could share your findings on > other implementations for that issue, as it would help us decide > whether to deprecate that behavior. > #4. We have included the test for libraries i.e., OpenSSL, GnuTLS, MbedTLS, MatrixSSL, JSSE, CPython SSL and applications i.e., HttpClient, cURL (default configuration). So far only GnuTLS, MbedTLS and MatrixSSL have this behavior, while others perform the check against only IP address in SAN when given IPv4 format string. Just a little inside info: OpenSSL lets applications choose identifier type for verification, the library therefore doesn't encounter this problem. We have also reported this to MatrixSSL, which the developer has decided to release a new version with an option flag for selecting identifier type similar to OpenSSL approach. MbedTLS does not support IP address certificate, so they do not check IP-address SAN certificate anyhow. >> The first observation we make is that the set of valid domain names is >> a superset of the set of valid IP addresses. Let assume that attacker >> targets SSL/TLS connections to the server with IP address >> 85.130.200.4. The IP address 85.130.200.4 can be considered as a >> subdomain of the top level domain 200.4. One may point out that .4 is, >> currently, not a valid top level domain. However new top level domains >> are being added frequently upon request. Since there is no fundamental >> restriction in the format of a top level domain, it is completely >> within the realm of possibility that purely arithmetic top level >> domains will appear in the near future. To perform the attack, the >> attacker is generating a certificate for the subdomain of 200.4 [...] > > That is certainly a concern. > > regards, > Nikos From ametzler at bebt.de Thu Mar 16 15:39:36 2017 From: ametzler at bebt.de (Andreas Metzler) Date: Thu, 16 Mar 2017 15:39:36 +0100 Subject: [gnutls-devel] Debian bug #857436: libgnutls-openssl27: OpenSSL wrapper not exposing TLS 1.1/1.2 ciphers In-Reply-To: <20170311143459.4zsasws33l6s3flg@argenau.bebt.de> References: <20170311143459.4zsasws33l6s3flg@argenau.bebt.de> Message-ID: <20170316143936.juej73aqg6elxdpx@argenau.bebt.de> On 2017-03-11 Andreas Metzler wrote: [...]> 8X---------------------------------------------- > Certain packages that rely on this OpenSSL wrapper library are unable to > connect using TLS 1.1/1.2 cipher suites. > Even though the server (and the client, when compiled against OpenSSL) > supports the full array of TLS 1.1/1.2 ciphers, the package as provided > seems to be limited to only TLS 1.0 ciphers. Actually this *seems* to be trivially fixable. /Seems/ because I assume there is/was a reason for using a custom priority string. ;-) cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-NORMAL-priority-for-SSLv23_-_method.patch Type: text/x-diff Size: 1103 bytes Desc: not available URL: From ametzler at bebt.de Thu Mar 16 18:03:48 2017 From: ametzler at bebt.de (Andreas Metzler) Date: Thu, 16 Mar 2017 18:03:48 +0100 Subject: [gnutls-devel] gnutls.pc includes invalid flags Message-ID: <20170316170348.gvp35jjvyxclvkjg@argenau.bebt.de> Hello, this is https://bugs.debian.org/857943 reported by Aaron M. Ucko: ---------------- he output of `pkg-config gnutls --libs --static` includes a flag of the form -R/usr/lib/$DEB_HOST_MULTIARCH, which is not only superfluous but also outright broken without a leading -Wl,: $ gcc `pkg-config gnutls --libs --static` gcc: error: unrecognized command line option ?-R?; did you mean ?-R?? $ pkg-config gnutls --libs --static -lgnutls -lz -R/usr/lib/x86_64-linux-gnu -lp11-kit -lgmp -lnettle -lhogweed -lgmp -lnettle -ltasn1 -lidn -lp11-kit -lz ---------------- Attached patch works for me. (I am not totally sure whether it is useful to carter for incomplete pkg-config setups at all. If there is no zlib.pc, the user will probably not install gnutls.pc either.) cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Do-not-use-LTLIBZ-in-gnutls.pc.in.patch Type: text/x-diff Size: 1752 bytes Desc: not available URL: From n.mavrogiannopoulos at gmail.com Fri Mar 17 11:41:40 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 17 Mar 2017 11:41:40 +0100 Subject: [gnutls-devel] code coverage reports Message-ID: Hi, I've created a small project to measure the coverage of gnutls and store the output in web-pages in [0]. The results can be seen either on the coverage badges on gnutls gitlab site, or at: https://gnutls.gitlab.io/coverage/master/ https://gnutls.gitlab.io/coverage/3.5.x/ On the content, it seems that a large majority (70%+) of the code is tested. However, there is still functionality and error paths that remain untested. There are code paths such as TPM which cannot be tested in an automated way (we would need some kind of TPM 1.2 emulator), and openpgp support will most likely never get any improvement in testing since it is deprecated code. For the rest, I'd appreciate help on increasing the existing's code test coverage. The coverage pages are set to auto generate on every release of gnutls. regards, Nikos [0]. https://gitlab.com/gnutls/coverage From nmav at gnutls.org Fri Mar 17 12:07:39 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 17 Mar 2017 12:07:39 +0100 Subject: [gnutls-devel] gnutls.pc includes invalid flags In-Reply-To: <20170316170348.gvp35jjvyxclvkjg@argenau.bebt.de> References: <20170316170348.gvp35jjvyxclvkjg@argenau.bebt.de> Message-ID: On Thu, Mar 16, 2017 at 6:03 PM, Andreas Metzler wrote: > Hello, > > this is https://bugs.debian.org/857943 reported by Aaron M. Ucko: > ---------------- > he output of `pkg-config gnutls --libs --static` includes a flag of > the form -R/usr/lib/$DEB_HOST_MULTIARCH, which is not only superfluous > but also outright broken without a leading -Wl,: > > $ gcc `pkg-config gnutls --libs --static` > gcc: error: unrecognized command line option ?-R?; did you mean ?-R?? > $ pkg-config gnutls --libs --static > -lgnutls -lz -R/usr/lib/x86_64-linux-gnu -lp11-kit -lgmp -lnettle -lhogweed -lgmp -lnettle -ltasn1 -lidn -lp11-kit -lz > ---------------- > Attached patch works for me. > > (I am not totally sure whether it is useful to carter for incomplete > pkg-config setups at all. If there is no zlib.pc, the user will probably > not install gnutls.pc either.) I'm thinking that this may apply to all the LT variables used Libs.private. Would it still work if we use the non LT version of the variables (e.g., LIBZ in that case?) regards, Nikos From ludo at gnu.org Fri Mar 17 12:09:53 2017 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Fri, 17 Mar 2017 12:09:53 +0100 Subject: [gnutls-devel] code coverage reports In-Reply-To: (Nikos Mavrogiannopoulos's message of "Fri, 17 Mar 2017 11:41:40 +0100") References: Message-ID: <87var8f9by.fsf@gnu.org> Hello, Nikos Mavrogiannopoulos skribis: > I've created a small project to measure the coverage of gnutls and > store the output in web-pages in [0]. The results can be seen either > on the coverage badges on gnutls gitlab site, or at: > https://gnutls.gitlab.io/coverage/master/ > https://gnutls.gitlab.io/coverage/3.5.x/ Nice! It looks like the Guile bindings are not built. Could you enable them? Several years ago, running the test suite that comes with the Guile bindings noticeably improved test coverage of GnuTLS. The situation has probably changed since then, but it might still be a good thing to have. > The coverage pages are set to auto generate on every release of gnutls. It would be nice to do it as part of the CI jobs, like we did in . Thanks, Ludo?. From n.mavrogiannopoulos at gmail.com Fri Mar 17 12:51:50 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 17 Mar 2017 12:51:50 +0100 Subject: [gnutls-devel] code coverage reports In-Reply-To: <87var8f9by.fsf@gnu.org> References: <87var8f9by.fsf@gnu.org> Message-ID: On Fri, Mar 17, 2017 at 12:09 PM, Ludovic Court?s wrote: > Hello, > > Nikos Mavrogiannopoulos skribis: > >> I've created a small project to measure the coverage of gnutls and >> store the output in web-pages in [0]. The results can be seen either >> on the coverage badges on gnutls gitlab site, or at: >> https://gnutls.gitlab.io/coverage/master/ >> https://gnutls.gitlab.io/coverage/3.5.x/ > > Nice! It looks like the Guile bindings are not built. Could you enable > them? They are. I see the guile tests being run at: https://gitlab.com/gnutls/coverage/builds/12431503 >> The coverage pages are set to auto generate on every release of gnutls. > It would be nice to do it as part of the CI jobs, like we did in > . There is a coverage build as part of the CI jobs, but it only updates the coverage percentage number as shown in gitlab.com/gnutls/gnutls. It does not update the web pages, because I haven't figured a way to do that without overwriting the existing pages (which in that case are the www.gnutls.org web site). I'm not a gitlab power user, so any suggestion is welcome. regards, Nikos From n.mavrogiannopoulos at gmail.com Fri Mar 17 15:15:42 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 17 Mar 2017 15:15:42 +0100 Subject: [gnutls-devel] GnuTLS hostname checking bug report In-Reply-To: References: Message-ID: On Thu, Mar 16, 2017 at 5:56 AM, Suphannee Sivakorn wrote: >>> 1. Attempting to match CN when any SubjectAltName identifiers present (RFC 6125) >>> Section 6.3 of RFC 6125 prohibits clients from attempting to match CN >>> if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any >>> application-specific identifier types supported by the client. We >>> found that GnuTLS violates this requirement. The function >>> gnutls_x509_crt_check_hostname(2), which supports hostname >>> verification for hostname and IP address, attempts to match >>> certificate CN even when there is a subjectAltName identifier >>> presents, e.g., IP address. However, the library follows the >>> requirement when subjectAltName DNS presents. >> >> That is quite interesting. The actual text of RFC6125 is: >> "Security Warning: A client MUST NOT seek a match for a reference >> identifier of CN-ID if the presented identifiers include a DNS-ID, >> SRV-ID, URI-ID, or any application-specific identifier types >> supported by the client." >> >> My understanding of the text is that, the last part of the sentence >> implies that the prohibition of falling back to CN-ID matching applies >> when SRV-ID and URI-ID are supported. Given that gnutls doesn't >> support SRV-ID or URI-ID matching, it falls back immediately after the >> DNS-ID is checked. I may be wrong though, and I'm forwarding your >> message to the gnutls development list for further discussion. >> > > #1. The actual text also includes "or any application-specific > identifier types". As the function gnutls_x509_crt_check_hostname() > also supports IP address identifier, we believe that if IP-address/DNS > in SubjectAltName presents, the check for CN should be skipped. You are right. I've included such an enhancement in the following patch set. https://gitlab.com/gnutls/gnutls/merge_requests/314 >>> 4. Matching IPv4 string hostname with subjectAltName DNS >>> We found that giving IPv4 format string as hostname, GnuTLS attempts >>> to match this string with DNS attribute in the certificate >>> subjectAltName when IP address attribute in the certificate >>> subjectAltName does not match or present. Since RFC 1123 allows the >>> domain name to be letter or digit, this introduced valid DNS names >>> which are identical to IP addresses. >> >> That is an unfortunate but documented behavior for certain broken >> situations. See: >> http://www.gnutls.org/manual/html_node/X509-certificate-API.html#index-gnutls_005fx509_005fcrt_005fcheck_005fhostname2 >> >> It used to be that the DNS field contained IP addresses in some big >> PKI deployments. I'd appreciate if you could share your findings on >> other implementations for that issue, as it would help us decide >> whether to deprecate that behavior. > #4. We have included the test for libraries i.e., OpenSSL, GnuTLS, > MbedTLS, MatrixSSL, JSSE, CPython SSL and applications i.e., > HttpClient, cURL (default configuration). So far only GnuTLS, MbedTLS > and MatrixSSL have this behavior, while others perform the check > against only IP address in SAN when given IPv4 format string. Thank you. I think we can plan for its removal then. regards, Nikos From martin at martin.st Fri Mar 17 22:46:00 2017 From: martin at martin.st (=?ISO-8859-15?Q?Martin_Storsj=F6?=) Date: Fri, 17 Mar 2017 23:46:00 +0200 (EET) Subject: [gnutls-devel] gnutls 3.5.10 In-Reply-To: <1488783939.18801.2.camel@gnutls.org> References: <1488783939.18801.2.camel@gnutls.org> Message-ID: On Mon, 6 Mar 2017, Nikos Mavrogiannopoulos wrote: > GnuTLS may be downloaded directly from > .??A list of GnuTLS mirrors can be > found at . > > Here are the XZ compressed sources: > > ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.10.tar.xz I can't find this release in any of the mirrors, only on the main FTP. Is this expected? // Martin From ludo at gnu.org Sat Mar 18 11:13:18 2017 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Sat, 18 Mar 2017 11:13:18 +0100 Subject: [gnutls-devel] code coverage reports In-Reply-To: (Nikos Mavrogiannopoulos's message of "Fri, 17 Mar 2017 12:51:50 +0100") References: <87var8f9by.fsf@gnu.org> Message-ID: <87h92qc2pt.fsf@gnu.org> Hi Nikos, Nikos Mavrogiannopoulos skribis: > On Fri, Mar 17, 2017 at 12:09 PM, Ludovic Court?s wrote: >> Hello, >> >> Nikos Mavrogiannopoulos skribis: >> >>> I've created a small project to measure the coverage of gnutls and >>> store the output in web-pages in [0]. The results can be seen either >>> on the coverage badges on gnutls gitlab site, or at: >>> https://gnutls.gitlab.io/coverage/master/ >>> https://gnutls.gitlab.io/coverage/3.5.x/ >> >> Nice! It looks like the Guile bindings are not built. Could you enable >> them? > > They are. I see the guile tests being run at: > https://gitlab.com/gnutls/coverage/builds/12431503 Oh indeed. Not sure why the guile/ sub-directory doesn?t show up in the lcov pages above. Maybe on the next update? Ludo?. From ametzler at bebt.de Sat Mar 18 13:52:51 2017 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 18 Mar 2017 13:52:51 +0100 Subject: [gnutls-devel] gnutls.pc includes invalid flags In-Reply-To: References: <20170316170348.gvp35jjvyxclvkjg@argenau.bebt.de> Message-ID: <20170318125251.jqgog2ujhgo4uij6@argenau.bebt.de> On 2017-03-17 Nikos Mavrogiannopoulos wrote: > On Thu, Mar 16, 2017 at 6:03 PM, Andreas Metzler wrote: >> this is https://bugs.debian.org/857943 reported by Aaron M. Ucko: >> ---------------- >> he output of `pkg-config gnutls --libs --static` includes a flag of >> the form -R/usr/lib/$DEB_HOST_MULTIARCH, which is not only superfluous >> but also outright broken without a leading -Wl,: >> $ gcc `pkg-config gnutls --libs --static` >> gcc: error: unrecognized command line option ?-R?; did you mean ?-R?? >> $ pkg-config gnutls --libs --static >> -lgnutls -lz -R/usr/lib/x86_64-linux-gnu -lp11-kit -lgmp -lnettle -lhogweed -lgmp -lnettle -ltasn1 -lidn -lp11-kit -lz >> ---------------- >> Attached patch works for me. >> (I am not totally sure whether it is useful to carter for incomplete >> pkg-config setups at all. If there is no zlib.pc, the user will probably >> not install gnutls.pc either.) > I'm thinking that this may apply to all the LT variables used > Libs.private. Hello, I think so, too. It just has not hit us at Debian yet since the other @LT variables in gnutls.pc.in expand to empty strings in our builds. > Would it still work if we use the non LT version of the > variables (e.g., LIBZ in that case?) It probably would work, but definitely is not pretty, "./configure --libdir=/usr/lib/x86_64-linux-gnu" will produce these output variables when libz.so is in /usr/lib/x86_64-linux-gnu (which is in the standard linker search path): HAVE_LIBZ=yes LIBZ=/usr/lib/x86_64-linux-gnu/libz.so -Wl,-rpath -Wl,/usr/lib/x86_64-linux-gnu LIBZ_PREFIX= LTLIBZ=-L/usr/lib/x86_64-linux-gnu -lz -R/usr/lib/x86_64-linux-gnu This seems to be a general problem with AC_LIB_HAVE_LINKFLAGS. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From nmav at gnutls.org Sat Mar 18 17:53:17 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 18 Mar 2017 17:53:17 +0100 Subject: [gnutls-devel] gnutls 3.5.10 In-Reply-To: References: <1488783939.18801.2.camel@gnutls.org> Message-ID: <1489855997.4127.3.camel@gnutls.org> On Fri, 2017-03-17 at 23:46 +0200, Martin Storsj? wrote: > On Mon, 6 Mar 2017, Nikos Mavrogiannopoulos wrote: > > > GnuTLS may be downloaded directly from > > .??A list of GnuTLS mirrors > can be > > found at . > > > > Here are the XZ compressed sources: > > > > ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.10.tar.xz > > I can't find this release in any of the mirrors, only on the main > FTP. Is?this expected? No?(adding Werner). I've did a quick scan of the mirrors and got the following results. The following did not respond: ftp://mirror.tje.me.uk/pub/mirrors/ftp.gnupg.org ftp://ftp.iasi.roedu.net/pub/mirrors/ftp.gnupg.org/ ftp://ftp.gnupg.ca/ The following did not update (gnutls) since last month's release: https://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/ http://artfiles.org/gnupg.org http://gd.tuwien.ac.at/privacy/gnupg/ The following did not mirror gnutls at all: ftp://ftp.surfnet.nl/pub/security/gnupg/ ftp://ftp.bit.nl/mirror/gnupg/ The rest of the servers look ok. regards, Nikos From n.mavrogiannopoulos at gmail.com Sat Mar 18 19:23:14 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sat, 18 Mar 2017 19:23:14 +0100 Subject: [gnutls-devel] gnutls.pc includes invalid flags In-Reply-To: <20170318125251.jqgog2ujhgo4uij6@argenau.bebt.de> References: <20170316170348.gvp35jjvyxclvkjg@argenau.bebt.de> <20170318125251.jqgog2ujhgo4uij6@argenau.bebt.de> Message-ID: <1489861394.4127.6.camel@gmail.com> On Sat, 2017-03-18 at 13:52 +0100, Andreas Metzler wrote: > On 2017-03-17 Nikos Mavrogiannopoulos wrote: > > On Thu, Mar 16, 2017 at 6:03 PM, Andreas Metzler > > wrote: > > > this is https://bugs.debian.org/857943 reported by Aaron M. Ucko: > > > ---------------- > > > he output of `pkg-config gnutls --libs --static` includes a flag > > > of > > > the form -R/usr/lib/$DEB_HOST_MULTIARCH, which is not only > > > superfluous > > > but also outright broken without a leading -Wl,: > > > $ gcc `pkg-config gnutls --libs --static` > > > gcc: error: unrecognized command line option ?-R?; did you mean > > > ?-R?? > > > $ pkg-config gnutls --libs --static > > > -lgnutls -lz -R/usr/lib/x86_64-linux-gnu?????-lp11-kit???-lgmp > > > -lnettle -lhogweed -lgmp -lnettle -ltasn1 -lidn -lp11-kit -lz > > > ---------------- > > > Attached patch works for me. > > > (I am not totally sure whether it is useful to carter for > > > incomplete > > > pkg-config setups at all. If there is no zlib.pc, the user will > > > probably > > > not install gnutls.pc either.) > > I'm thinking that this may apply to all the LT variables used > > Libs.private. > > Hello, > > I think so, too. It just has not hit us at Debian yet since the other > @LT variables in gnutls.pc.in expand to empty strings in our builds. > > > Would it still work if we use the non LT version of the > > variables (e.g., LIBZ in that case?) > > It probably would work, but definitely is not pretty, "./configure > --libdir=/usr/lib/x86_64-linux-gnu" will produce these output > variables > when libz.so is in /usr/lib/x86_64-linux-gnu (which is in the > standard > linker search path): > > HAVE_LIBZ=yes > LIBZ=/usr/lib/x86_64-linux-gnu/libz.so -Wl,-rpath > -Wl,/usr/lib/x86_64-linux-gnu > LIBZ_PREFIX= > LTLIBZ=-L/usr/lib/x86_64-linux-gnu -lz -R/usr/lib/x86_64-linux-gnu > > This seems to be a general problem with AC_LIB_HAVE_LINKFLAGS. I've modified all the flags to remove the libtool variables, and added a small test for compilation using these flags: https://gitlab.com/gnutls/gnutls/merge_requests/317 This will not address the "ugliness" but at least would ensure that these flags are reasonable and lead to compilation. If you have any suggestion on something we could additionally check with pkg-config, let me know. regards, Nikos From martin at martin.st Sat Mar 18 21:22:59 2017 From: martin at martin.st (=?ISO-8859-15?Q?Martin_Storsj=F6?=) Date: Sat, 18 Mar 2017 22:22:59 +0200 (EET) Subject: [gnutls-devel] gnutls 3.5.10 In-Reply-To: <1489855997.4127.3.camel@gnutls.org> References: <1488783939.18801.2.camel@gnutls.org> <1489855997.4127.3.camel@gnutls.org> Message-ID: On Sat, 18 Mar 2017, Nikos Mavrogiannopoulos wrote: > On Fri, 2017-03-17 at 23:46 +0200, Martin Storsj? wrote: >> On Mon, 6 Mar 2017, Nikos Mavrogiannopoulos wrote: >> >>> GnuTLS may be downloaded directly from >>> .??A list of GnuTLS mirrors >> can be >>> found at . >>> >>> Here are the XZ compressed sources: >>> >>> ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.10.tar.xz >> >> I can't find this release in any of the mirrors, only on the main >> FTP. Is?this expected? > > No?(adding Werner). I've did a quick scan of the mirrors and got the > following results. > > The following did not respond: > ftp://mirror.tje.me.uk/pub/mirrors/ftp.gnupg.org > ftp://ftp.iasi.roedu.net/pub/mirrors/ftp.gnupg.org/ > ftp://ftp.gnupg.ca/ > > The following did not update (gnutls) since last month's release: > https://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/ > http://artfiles.org/gnupg.org > http://gd.tuwien.ac.at/privacy/gnupg/ > > The following did not mirror gnutls at all: > ftp://ftp.surfnet.nl/pub/security/gnupg/ > ftp://ftp.bit.nl/mirror/gnupg/ > > The rest of the servers look ok. I can't find it in the listing here either: https://www.gnupg.org/ftp/gcrypt/gnutls/v3.5/ Despite that, it does seem to exist on disk at that path though, so it just seems like the listing isn't refreshed after the last release was added. // Martin From wk at gnupg.org Sun Mar 19 10:41:32 2017 From: wk at gnupg.org (Werner Koch) Date: Sun, 19 Mar 2017 10:41:32 +0100 Subject: [gnutls-devel] gnutls 3.5.10 In-Reply-To: ("Martin =?utf-8?Q?Storsj=C3=B6=22's?= message of "Sat, 18 Mar 2017 22:22:59 +0200 (EET)") References: <1488783939.18801.2.camel@gnutls.org> <1489855997.4127.3.camel@gnutls.org> Message-ID: <87tw6pr4c3.fsf@wheatstone.g10code.de> On Sat, 18 Mar 2017 21:22, martin at martin.st said: > Despite that, it does seem to exist on disk at that path though, so it > just seems like the listing isn't refreshed after the last release was Hmmm, the cron jobs re-creates the index every 3 hours: # Create HTML index files for the FTP server 20 20/3 * * * root /etc/mk-ftp-index.html.sh it seems that it did not worked this time. I just kicked it and the index is now updated. I attach the script in case someone wants to check it for for a bug. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: mk-ftp-index.html.sh Type: text/x-sh Size: 1769 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ametzler at bebt.de Wed Mar 22 18:57:19 2017 From: ametzler at bebt.de (Andreas Metzler) Date: Wed, 22 Mar 2017 18:57:19 +0100 Subject: [gnutls-devel] gnutls.pc includes invalid flags In-Reply-To: <1489861394.4127.6.camel@gmail.com> References: <20170316170348.gvp35jjvyxclvkjg@argenau.bebt.de> <20170318125251.jqgog2ujhgo4uij6@argenau.bebt.de> <1489861394.4127.6.camel@gmail.com> Message-ID: <20170322175719.utrnesjtybbwgsjk@argenau.bebt.de> On 2017-03-18 Nikos Mavrogiannopoulos wrote: [...] > I've modified all the flags to remove the libtool variables, and added > a small test for compilation using these flags: > https://gitlab.com/gnutls/gnutls/merge_requests/317 > This will not address the "ugliness" but at least would ensure that > these flags are reasonable and lead to compilation. If you have any > suggestion on something we could additionally check with pkg-config, > let me know. This issue is still open: | ... fix duplicate reference to zlib. If zlib.pc was present it would | be listed in both Requires.private and Libs.private. I had listed this in suggested patch's commit message but forgot to mention it in the mail, sorry. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From nmav at gnutls.org Thu Mar 23 08:03:25 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 23 Mar 2017 08:03:25 +0100 Subject: [gnutls-devel] gnutls.pc includes invalid flags In-Reply-To: <20170322175719.utrnesjtybbwgsjk@argenau.bebt.de> References: <20170316170348.gvp35jjvyxclvkjg@argenau.bebt.de> <20170318125251.jqgog2ujhgo4uij6@argenau.bebt.de> <1489861394.4127.6.camel@gmail.com> <20170322175719.utrnesjtybbwgsjk@argenau.bebt.de> Message-ID: On Wed, Mar 22, 2017 at 6:57 PM, Andreas Metzler wrote: > On 2017-03-18 Nikos Mavrogiannopoulos wrote: > [...] >> I've modified all the flags to remove the libtool variables, and added >> a small test for compilation using these flags: >> https://gitlab.com/gnutls/gnutls/merge_requests/317 > >> This will not address the "ugliness" but at least would ensure that >> these flags are reasonable and lead to compilation. If you have any >> suggestion on something we could additionally check with pkg-config, >> let me know. > > This issue is still open: > | ... fix duplicate reference to zlib. If zlib.pc was present it would > | be listed in both Requires.private and Libs.private. > > I had listed this in suggested patch's commit message but forgot to > mention it in the mail, sorry. I saw it but didn't have anything good to propose and then I forgot about it. What about something like that patch? regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: libz-pc.patch Type: text/x-patch Size: 1454 bytes Desc: not available URL: From ametzler at bebt.de Fri Mar 24 19:16:47 2017 From: ametzler at bebt.de (Andreas Metzler) Date: Fri, 24 Mar 2017 19:16:47 +0100 Subject: [gnutls-devel] gnutls.pc includes invalid flags In-Reply-To: References: <20170316170348.gvp35jjvyxclvkjg@argenau.bebt.de> <20170318125251.jqgog2ujhgo4uij6@argenau.bebt.de> <1489861394.4127.6.camel@gmail.com> <20170322175719.utrnesjtybbwgsjk@argenau.bebt.de> Message-ID: <20170324181647.t6aexdtiro2ylmut@argenau.bebt.de> On 2017-03-23 Nikos Mavrogiannopoulos wrote: > On Wed, Mar 22, 2017 at 6:57 PM, Andreas Metzler wrote: [...] [...] > > This issue is still open: > > | ... fix duplicate reference to zlib. If zlib.pc was present it would > > | be listed in both Requires.private and Libs.private. > > > > I had listed this in suggested patch's commit message but forgot to > > mention it in the mail, sorry. > I saw it but didn't have anything good to propose and then I forgot > about it. What about something like that patch? [...] Works for me. Tested both with and without having zlib.pc available. thanks, cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From ametzler at bebt.de Sat Mar 25 15:30:43 2017 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 25 Mar 2017 15:30:43 +0100 Subject: [gnutls-devel] gnutls.pc includes invalid flags In-Reply-To: <20170324181647.t6aexdtiro2ylmut@argenau.bebt.de> References: <20170316170348.gvp35jjvyxclvkjg@argenau.bebt.de> <20170318125251.jqgog2ujhgo4uij6@argenau.bebt.de> <1489861394.4127.6.camel@gmail.com> <20170322175719.utrnesjtybbwgsjk@argenau.bebt.de> <20170324181647.t6aexdtiro2ylmut@argenau.bebt.de> Message-ID: <20170325143043.gufyrc2utunnclu2@argenau.bebt.de> On 2017-03-24 Andreas Metzler wrote: > On 2017-03-23 Nikos Mavrogiannopoulos wrote: > > On Wed, Mar 22, 2017 at 6:57 PM, Andreas Metzler wrote: > [...] > [...] > > > This issue is still open: > > > | ... fix duplicate reference to zlib. If zlib.pc was present it would > > > | be listed in both Requires.private and Libs.private. > > > > > > I had listed this in suggested patch's commit message but forgot to > > > mention it in the mail, sorry. > > I saw it but didn't have anything good to propose and then I forgot > > about it. What about something like that patch? > [...] > Works for me. Tested both with and without having zlib.pc available. Now in GIT, thank you! Almost the same issue exist for p11-kit, it is also in both Libs.private and Requires.private. However since compilation requires that p11-kit-1.pc is present and does not allow non-pkgconfig p11-kit the fix is trivial. Just drop @P11_KIT_LIBS@ from Libs.private. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From n.mavrogiannopoulos at gmail.com Sat Mar 25 21:53:24 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sat, 25 Mar 2017 21:53:24 +0100 Subject: [gnutls-devel] gnutls.pc includes invalid flags In-Reply-To: <20170325143043.gufyrc2utunnclu2@argenau.bebt.de> References: <20170316170348.gvp35jjvyxclvkjg@argenau.bebt.de> <20170318125251.jqgog2ujhgo4uij6@argenau.bebt.de> <1489861394.4127.6.camel@gmail.com> <20170322175719.utrnesjtybbwgsjk@argenau.bebt.de> <20170324181647.t6aexdtiro2ylmut@argenau.bebt.de> <20170325143043.gufyrc2utunnclu2@argenau.bebt.de> Message-ID: <1490475204.21455.0.camel@gmail.com> On Sat, 2017-03-25 at 15:30 +0100, Andreas Metzler wrote: > On 2017-03-24 Andreas Metzler wrote: > > On 2017-03-23 Nikos Mavrogiannopoulos wrote: > > > On Wed, Mar 22, 2017 at 6:57 PM, Andreas Metzler > > e> wrote: > > > > [...] > > [...] > > > > This issue is still open: > > > > > ... fix duplicate reference to zlib. If zlib.pc was present > > > > > it would > > > > > be listed in both Requires.private and Libs.private. > > > > > > > > I had listed this in suggested patch's commit message??but > > > > forgot to > > > > mention it in the mail, sorry. > > > I saw it but didn't have anything good to propose and then I > > > forgot > > > about it. What about something like that patch? > > > > [...] > > Works for me. Tested both with and without having zlib.pc > > available. > > Now in GIT, thank you! > > Almost the same issue exist for p11-kit, it is also in both > Libs.private > and Requires.private. However since compilation requires that > p11-kit-1.pc is present and does not allow non-pkgconfig p11-kit the > fix > is trivial. Just drop @P11_KIT_LIBS@ from Libs.private. Thank you. I've committed a patch to address it. From alon.barlev at gmail.com Sun Mar 26 10:29:52 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 26 Mar 2017 11:29:52 +0300 Subject: [gnutls-devel] [TESTS] gnutls-3.5 key exchange fails in sparc for ecdhe x25519 rsa Message-ID: Hi, Can anyone please assist in determine why sparc tests fails? Logs are available here[1] It seems that the ecdhe x25519 rsa is an issue. Thanks! Alon [1] https://bugs.gentoo.org/show_bug.cgi?id=613418 From nmav at gnutls.org Mon Mar 27 11:32:41 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 27 Mar 2017 11:32:41 +0200 Subject: [gnutls-devel] [TESTS] gnutls-3.5 key exchange fails in sparc for ecdhe x25519 rsa In-Reply-To: References: Message-ID: On Sun, Mar 26, 2017 at 10:29 AM, Alon Bar-Lev wrote: > Hi, > Can anyone please assist in determine why sparc tests fails? > Logs are available here[1] > It seems that the ecdhe x25519 rsa is an issue. Does nettle's test suite succeed? Which version of nettle is it being used with? regards, Nikos From ametzler at bebt.de Thu Mar 30 19:05:33 2017 From: ametzler at bebt.de (Andreas Metzler) Date: Thu, 30 Mar 2017 19:05:33 +0200 Subject: [gnutls-devel] Debian bug #857436: libgnutls-openssl27: OpenSSL wrapper not exposing TLS 1.1/1.2 ciphers In-Reply-To: <20170316143936.juej73aqg6elxdpx@argenau.bebt.de> References: <20170311143459.4zsasws33l6s3flg@argenau.bebt.de> <20170316143936.juej73aqg6elxdpx@argenau.bebt.de> Message-ID: <20170330170533.exf7fofnoteu5zp4@argenau.bebt.de> On 2017-03-16 Andreas Metzler wrote: > On 2017-03-11 Andreas Metzler wrote: > [...]> 8X---------------------------------------------- >> Certain packages that rely on this OpenSSL wrapper library are unable to >> connect using TLS 1.1/1.2 cipher suites. >> Even though the server (and the client, when compiled against OpenSSL) >> supports the full array of TLS 1.1/1.2 ciphers, the package as provided >> seems to be limited to only TLS 1.0 ciphers. > Actually this *seems* to be trivially fixable. Ping? From nmav at gnutls.org Fri Mar 31 20:49:43 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 31 Mar 2017 20:49:43 +0200 Subject: [gnutls-devel] Debian bug #857436: libgnutls-openssl27: OpenSSL wrapper not exposing TLS 1.1/1.2 ciphers In-Reply-To: <20170330170533.exf7fofnoteu5zp4@argenau.bebt.de> References: <20170311143459.4zsasws33l6s3flg@argenau.bebt.de> <20170316143936.juej73aqg6elxdpx@argenau.bebt.de> <20170330170533.exf7fofnoteu5zp4@argenau.bebt.de> Message-ID: On Thu, Mar 30, 2017 at 7:05 PM, Andreas Metzler wrote: > On 2017-03-16 Andreas Metzler wrote: >> On 2017-03-11 Andreas Metzler wrote: >> [...]> 8X---------------------------------------------- >>> Certain packages that rely on this OpenSSL wrapper library are unable to >>> connect using TLS 1.1/1.2 cipher suites. > >>> Even though the server (and the client, when compiled against OpenSSL) >>> supports the full array of TLS 1.1/1.2 ciphers, the package as provided >>> seems to be limited to only TLS 1.0 ciphers. > >> Actually this *seems* to be trivially fixable. > > Ping? Hi, Possibly, but I have not checked it. If you have any patch for it please go for it and submit an MR. regards, Nikos