From ludo at gnu.org Sat Jun 1 17:09:40 2019 From: ludo at gnu.org (=?UTF-8?q?Ludovic=20Court=C3=A8s?=) Date: Sat, 1 Jun 2019 17:09:40 +0200 Subject: [gnutls-help] [PATCH 2/2] guile: Add support for Guile 3.0. In-Reply-To: <20190601150940.6086-1-ludo@gnu.org> References: <20190601150940.6086-1-ludo@gnu.org> Message-ID: <20190601150940.6086-3-ludo@gnu.org> * configure.ac: Add 3.0 to 'GUILE_PKG', as well as the previously-supported versions. * doc/gnutls-guile.texi (Guile Preparations): Update list of supported versions. --- configure.ac | 4 ++-- doc/gnutls-guile.texi | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/configure.ac b/configure.ac index e0c5c25d5b..9a3de8a9f9 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ dnl Process this file with autoconf to produce a configure script. -# Copyright (C) 2000-2012, 2016 Free Software Foundation, Inc. +# Copyright (C) 2000-2012, 2016, 2019 Free Software Foundation, Inc. # # Author: Nikos Mavrogiannopoulos, Simon Josefsson # @@ -866,7 +866,7 @@ if test "$opt_guile_bindings" = "yes"; then AC_PATH_PROG([GUILD], [guild]) AC_SUBST([GUILD]) - GUILE_PKG + GUILE_PKG([3.0 2.2 2.0 1.8]) GUILE_PROGS GUILE_SITE_DIR GUILE_FLAGS diff --git a/doc/gnutls-guile.texi b/doc/gnutls-guile.texi index b53349acab..3e0b64d7eb 100644 --- a/doc/gnutls-guile.texi +++ b/doc/gnutls-guile.texi @@ -17,7 +17,7 @@ This manual is last updated @value{UPDATED} for version @value{VERSION} of GnuTLS. -Copyright @copyright{} 2001-2012, 2014, 2016 Free Software Foundation, Inc. +Copyright @copyright{} 2001-2012, 2014, 2016, 2019 Free Software Foundation, Inc. @quotation Permission is granted to copy, distribute and/or modify this document @@ -85,8 +85,8 @@ a large subset thereof is available. @node Guile Preparations @chapter Guile Preparations -The GnuTLS Guile bindings are available for Guile's 2.0 stable series, -as well as the forthcoming 2.2 series and the legacy 1.8 series. +The GnuTLS Guile bindings are available for the Guile 3.0 and 2.2 +series, as well as the legacy 2.0 and even 1.8 series. By default they are installed under the GnuTLS installation directory, typically @file{/usr/local/share/guile/site/}). Normally Guile -- 2.21.0 From ludo at gnu.org Sat Jun 1 17:09:39 2019 From: ludo at gnu.org (=?UTF-8?q?Ludovic=20Court=C3=A8s?=) Date: Sat, 1 Jun 2019 17:09:39 +0200 Subject: [gnutls-help] [PATCH 1/2] doc: Run guile with '-q'. In-Reply-To: <20190601150940.6086-1-ludo@gnu.org> References: <20190601150940.6086-1-ludo@gnu.org> Message-ID: <20190601150940.6086-2-ludo@gnu.org> This makes sure we don't load the user's ~/.guile. * doc/Makefile.am (GUILE_FOR_BUILD): Pass '-q'. --- doc/Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/Makefile.am b/doc/Makefile.am index 773ab6dc7f..74144edbcb 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -1,5 +1,5 @@ ## Process this file with automake to produce Makefile.in -# Copyright (C) 2000-2012 Free Software Foundation, Inc. +# Copyright (C) 2000-2012, 2019 Free Software Foundation, Inc. # # Author: Nikos Mavrogiannopoulos # @@ -492,7 +492,7 @@ if HAVE_GUILE GUILE_FOR_BUILD = \ GUILE_AUTO_COMPILE=0 \ - $(GUILE) -L $(top_srcdir)/guile/modules + $(GUILE) -q -L $(top_srcdir)/guile/modules SNARF_CPPFLAGS = -I$(top_srcdir) -I$(top_builddir) \ -I$(top_srcdir)/lib/includes -I$(top_builddir)/lib/includes \ -- 2.21.0 From ludo at gnu.org Sat Jun 1 17:09:38 2019 From: ludo at gnu.org (=?UTF-8?q?Ludovic=20Court=C3=A8s?=) Date: Sat, 1 Jun 2019 17:09:38 +0200 Subject: [gnutls-help] [PATCH 0/2] Add support for Guile 3.0 Message-ID: <20190601150940.6086-1-ludo@gnu.org> Hello! These patches ?add support? for the upcoming Guile 3.0, which was not terribly difficult. ;-) I think it can be applied to all the branches. Thanks, Ludo?. Ludovic Court?s (2): doc: Run guile with '-q'. guile: Add support for Guile 3.0. configure.ac | 4 ++-- doc/Makefile.am | 4 ++-- doc/gnutls-guile.texi | 6 +++--- 3 files changed, 7 insertions(+), 7 deletions(-) -- 2.21.0 From nmav at gnutls.org Mon Jun 3 13:07:40 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 3 Jun 2019 13:07:40 +0200 Subject: [gnutls-help] [PATCH 0/2] Add support for Guile 3.0 In-Reply-To: <20190601150940.6086-1-ludo@gnu.org> References: <20190601150940.6086-1-ludo@gnu.org> Message-ID: Hi Ludo, Would you like to send a merge request so we see whether these pass the CI tests? regards, Nikos btw. There are two issues opened over guile bindings, would it be possible to help with these? https://gitlab.com/gnutls/gnutls/issues?label_name%5B%5D=guile-bindings On Sat, Jun 1, 2019 at 5:10 PM Ludovic Court?s wrote: > > Hello! > > These patches ?add support? for the upcoming Guile 3.0, > which was not terribly difficult. ;-) > > I think it can be applied to all the branches. > > Thanks, > Ludo?. > > Ludovic Court?s (2): > doc: Run guile with '-q'. > guile: Add support for Guile 3.0. > > configure.ac | 4 ++-- > doc/Makefile.am | 4 ++-- > doc/gnutls-guile.texi | 6 +++--- > 3 files changed, 7 insertions(+), 7 deletions(-) > > -- > 2.21.0 > From ludo at gnu.org Mon Jun 3 16:59:19 2019 From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=) Date: Mon, 03 Jun 2019 16:59:19 +0200 Subject: [gnutls-help] [PATCH 0/2] Add support for Guile 3.0 In-Reply-To: (Nikos Mavrogiannopoulos's message of "Mon, 3 Jun 2019 13:07:40 +0200") References: <20190601150940.6086-1-ludo@gnu.org> Message-ID: <87sgsqd8ag.fsf@gnu.org> Hi Nikos, Nikos Mavrogiannopoulos skribis: > Would you like to send a merge request so we see whether these pass > the CI tests? The new GitLab ToS looked obnoxious to me so I didn?t agree to them, and thus lost my ability to interact there. My preference is to use email, but if merge requests are more convenient for you I can do like everyone else and happily ignore the issues; WDYT? > btw. There are two issues opened over guile bindings, would it be > possible to help with these? > https://gitlab.com/gnutls/gnutls/issues?label_name%5B%5D=guile-bindings They seem to be quite easy to address, I?ll take a look. Thanks, Ludo?. From nmav at gnutls.org Wed Jun 5 08:35:06 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 5 Jun 2019 08:35:06 +0200 Subject: [gnutls-help] [PATCH 0/2] Add support for Guile 3.0 In-Reply-To: <87sgsqd8ag.fsf@gnu.org> References: <20190601150940.6086-1-ludo@gnu.org> <87sgsqd8ag.fsf@gnu.org> Message-ID: On Mon, Jun 3, 2019 at 4:59 PM Ludovic Court?s wrote: > > Hi Nikos, > > Nikos Mavrogiannopoulos skribis: > > > Would you like to send a merge request so we see whether these pass > > the CI tests? > > The new GitLab ToS looked obnoxious to me so I didn?t agree to them, and > thus lost my ability to interact there. > > My preference is to use email, but if merge requests are more convenient > for you I can do like everyone else and happily ignore the issues; WDYT? I am not sure what do you mean by ignoring the issues. Could you elaborate? With the email approach someone else would have to open the MR, check any errors and report back. I can do it this time, though I don't want to commit to such a role. I've opened the MR at: https://gitlab.com/gnutls/gnutls/merge_requests/1018 The test results are at: https://gitlab.com/nmav/gnutls/pipelines/64750155 (the patches seem to miss the signoff-by flag) regards, Nikos > > > btw. There are two issues opened over guile bindings, would it be > > possible to help with these? > > https://gitlab.com/gnutls/gnutls/issues?label_name%5B%5D=guile-bindings > > They seem to be quite easy to address, I?ll take a look. > > Thanks, > Ludo?. From ludo at gnu.org Wed Jun 5 12:07:31 2019 From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=) Date: Wed, 05 Jun 2019 12:07:31 +0200 Subject: [gnutls-help] [PATCH 0/2] Add support for Guile 3.0 In-Reply-To: (Nikos Mavrogiannopoulos's message of "Wed, 5 Jun 2019 08:35:06 +0200") References: <20190601150940.6086-1-ludo@gnu.org> <87sgsqd8ag.fsf@gnu.org> Message-ID: <87pnns5org.fsf@gnu.org> Hi Nikos, Nikos Mavrogiannopoulos skribis: > On Mon, Jun 3, 2019 at 4:59 PM Ludovic Court?s wrote: >> >> Hi Nikos, >> >> Nikos Mavrogiannopoulos skribis: >> >> > Would you like to send a merge request so we see whether these pass >> > the CI tests? >> >> The new GitLab ToS looked obnoxious to me so I didn?t agree to them, and >> thus lost my ability to interact there. >> >> My preference is to use email, but if merge requests are more convenient >> for you I can do like everyone else and happily ignore the issues; WDYT? > > I am not sure what do you mean by ignoring the issues. Could you > elaborate? I meant ignore the issues with these ToS, such as the ?Indemnification? section at ; fundamentally, I want to contribute to GnuTLS, I don?t want to have to deal with GitLab B.V., but I think we already discussed it before. I also find it sad that a distributed VCS led to more centralization than we had before? I understand this service is convenient, in particular for many newcomers, but IMO we shouldn?t be blind to its costs. > With the email approach someone else would have to open the MR, check > any errors and report back. I can do it this time, though I don't want > to commit to such a role. > > I've opened the MR at: > https://gitlab.com/gnutls/gnutls/merge_requests/1018 > > The test results are at: > https://gitlab.com/nmav/gnutls/pipelines/64750155 Thanks for doing this! Like I said, I?ll resignedly accept the ToS and do that in the future if that?s more convenient for you. > (the patches seem to miss the signoff-by flag) The convention in GnuTLS is to add ?Signed-off-by? by the author? Thanks, Ludo?. From ludo at gnu.org Wed Jun 5 12:13:07 2019 From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=) Date: Wed, 05 Jun 2019 12:13:07 +0200 Subject: [gnutls-help] [PATCH 0/2] Add support for Guile 3.0 In-Reply-To: (Nikos Mavrogiannopoulos's message of "Wed, 5 Jun 2019 08:35:06 +0200") References: <20190601150940.6086-1-ludo@gnu.org> <87sgsqd8ag.fsf@gnu.org> Message-ID: <87imtk5oi4.fsf@gnu.org> Nikos Mavrogiannopoulos skribis: > The test results are at: > https://gitlab.com/nmav/gnutls/pipelines/64750155 fails with: --8<---------------cut here---------------start------------->8--- configure: checking for guile 3.0 configure: checking for guile 2.2 configure: found guile 2.2 checking for guile... (cached) /usr/bin/guile configure: error: found development files for Guile 2.2, but /usr/bin/guile has effective version 2.0 --8<---------------cut here---------------end--------------->8--- This is most likely a setup issue in the build environment and not related to this commit; likewise for ?doc-dist.Fedora? and ?minimal.Fedora.x86_64?. Thanks, Ludo?. From nmav at gnutls.org Wed Jun 5 13:46:28 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 5 Jun 2019 13:46:28 +0200 Subject: [gnutls-help] [PATCH 0/2] Add support for Guile 3.0 In-Reply-To: <87pnns5org.fsf@gnu.org> References: <20190601150940.6086-1-ludo@gnu.org> <87sgsqd8ag.fsf@gnu.org> <87pnns5org.fsf@gnu.org> Message-ID: On Wed, Jun 5, 2019 at 12:07 PM Ludovic Court?s wrote: > > Hi Nikos, > > Nikos Mavrogiannopoulos skribis: > > > On Mon, Jun 3, 2019 at 4:59 PM Ludovic Court?s wrote: > >> > >> Hi Nikos, > >> > >> Nikos Mavrogiannopoulos skribis: > >> > >> > Would you like to send a merge request so we see whether these pass > >> > the CI tests? > >> > >> The new GitLab ToS looked obnoxious to me so I didn?t agree to them, and > >> thus lost my ability to interact there. > >> > >> My preference is to use email, but if merge requests are more convenient > >> for you I can do like everyone else and happily ignore the issues; WDYT? > > > > I am not sure what do you mean by ignoring the issues. Could you > > elaborate? > > I meant ignore the issues with these ToS, such as the ?Indemnification? > section at ; fundamentally, I want to > contribute to GnuTLS, I don?t want to have to deal with GitLab B.V., but > I think we already discussed it before. I also find it sad that a > distributed VCS led to more centralization than we had before? That's true, though gitlab gives us the option to move data (issue tracker etc) elsewhere. The good thing is that there are options also, not only gitlab.com, but also gitlab.gnome.org (https://wiki.gnome.org/GitLab/IncubatorReqs ), and few other instances. The main benefit I see of gitlab.com is the CI, and the workflow improvements saving time in all involved parties. > > With the email approach someone else would have to open the MR, check > > any errors and report back. I can do it this time, though I don't want > > to commit to such a role. > > > > I've opened the MR at: > > https://gitlab.com/gnutls/gnutls/merge_requests/1018 > > > > The test results are at: > > https://gitlab.com/nmav/gnutls/pipelines/64750155 > > Thanks for doing this! > > Like I said, I?ll resignedly accept the ToS and do that in the future if > that?s more convenient for you. Thank you. I really appreciate it. > The convention in GnuTLS is to add ?Signed-off-by? by the author? Yes, there are few contribution guidelines that were changed over the years, one was this one. The full list is at: https://gitlab.com/gnutls/gnutls/blob/master/CONTRIBUTING.md The request for changes in the guidelines are usually tagged with the process tag in gitlab: https://gitlab.com/gnutls/gnutls/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Process regards, Nikos From ludo at gnu.org Thu Jun 6 10:19:42 2019 From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=) Date: Thu, 06 Jun 2019 10:19:42 +0200 Subject: [gnutls-help] [PATCH 0/2] Add support for Guile 3.0 In-Reply-To: (Nikos Mavrogiannopoulos's message of "Wed, 5 Jun 2019 13:46:28 +0200") References: <20190601150940.6086-1-ludo@gnu.org> <87sgsqd8ag.fsf@gnu.org> <87pnns5org.fsf@gnu.org> Message-ID: <87sgsnp1lt.fsf@gnu.org> Nikos Mavrogiannopoulos skribis: > On Wed, Jun 5, 2019 at 12:07 PM Ludovic Court?s wrote: [...] >> I meant ignore the issues with these ToS, such as the ?Indemnification? >> section at ; fundamentally, I want to >> contribute to GnuTLS, I don?t want to have to deal with GitLab B.V., but >> I think we already discussed it before. I also find it sad that a >> distributed VCS led to more centralization than we had before? > > That's true, though gitlab gives us the option to move data (issue > tracker etc) elsewhere. The good thing is that there are options also, > not only gitlab.com, but also gitlab.gnome.org > (https://wiki.gnome.org/GitLab/IncubatorReqs ), and few other > instances. I don?t mind having an account on gitlab.gnome.org or savannah.gnu.org: these are run by non-profit organizations with clear commitments. To contribute to GnuTLS, in practice I have to sign up to gitlab.com and agree their terms of service; I have to trust GitLab B.V. to be ?kind? to me and to GnuTLS in the future. It doesn?t really help that theoretically data from the issue tracker can be moved elsewhere. > The main benefit I see of gitlab.com is the CI, and the > workflow improvements saving time in all involved parties. Sure, I understand, even though it?s a workflow that doesn?t work well for me. >> The convention in GnuTLS is to add ?Signed-off-by? by the author? > > Yes, there are few contribution guidelines that were changed over the > years, one was this one. The full list is at: > https://gitlab.com/gnutls/gnutls/blob/master/CONTRIBUTING.md > > The request for changes in the guidelines are usually tagged with the > process tag in gitlab: > https://gitlab.com/gnutls/gnutls/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Process Oh, I see, thanks for the pointers. Back to the original patches, should I push a new branch to add the ?Signed-off-by? tag? Thanks, Ludo?. From nmav at gnutls.org Thu Jun 6 15:25:25 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 6 Jun 2019 15:25:25 +0200 Subject: [gnutls-help] [PATCH 0/2] Add support for Guile 3.0 In-Reply-To: <87sgsnp1lt.fsf@gnu.org> References: <20190601150940.6086-1-ludo@gnu.org> <87sgsqd8ag.fsf@gnu.org> <87pnns5org.fsf@gnu.org> <87sgsnp1lt.fsf@gnu.org> Message-ID: On Thu, Jun 6, 2019 at 10:19 AM Ludovic Court?s wrote: > Yes, there are few contribution guidelines that were changed over the > > years, one was this one. The full list is at: > > https://gitlab.com/gnutls/gnutls/blob/master/CONTRIBUTING.md > > > > The request for changes in the guidelines are usually tagged with the > > process tag in gitlab: > > https://gitlab.com/gnutls/gnutls/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Process > > Oh, I see, thanks for the pointers. > > Back to the original patches, should I push a new branch to add the > ?Signed-off-by? tag? I think that would be the best. I'll then close my MR. regards, Nikos From ludo at gnu.org Fri Jun 7 09:21:26 2019 From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=) Date: Fri, 07 Jun 2019 09:21:26 +0200 Subject: [gnutls-help] [PATCH 0/2] Add support for Guile 3.0 In-Reply-To: (Nikos Mavrogiannopoulos's message of "Thu, 6 Jun 2019 15:25:25 +0200") References: <20190601150940.6086-1-ludo@gnu.org> <87sgsqd8ag.fsf@gnu.org> <87pnns5org.fsf@gnu.org> <87sgsnp1lt.fsf@gnu.org> Message-ID: <87a7etkgi1.fsf@gnu.org> Nikos Mavrogiannopoulos skribis: > On Thu, Jun 6, 2019 at 10:19 AM Ludovic Court?s wrote: > > Yes, there are few contribution guidelines that were changed over the >> > years, one was this one. The full list is at: >> > https://gitlab.com/gnutls/gnutls/blob/master/CONTRIBUTING.md >> > >> > The request for changes in the guidelines are usually tagged with the >> > process tag in gitlab: >> > https://gitlab.com/gnutls/gnutls/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Process >> >> Oh, I see, thanks for the pointers. >> >> Back to the original patches, should I push a new branch to add the >> ?Signed-off-by? tag? > > I think that would be the best. I'll then close my MR. Done, thanks! https://gitlab.com/gnutls/gnutls/merge_requests/1020 Ludo?. From ludo at gnu.org Fri Jun 7 13:03:23 2019 From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=) Date: Fri, 07 Jun 2019 13:03:23 +0200 Subject: [gnutls-help] TLS 1.3 post-handshake authentication vs. exceptions Message-ID: <87d0jphd38.fsf@gnu.org> Hello, AIUI, TLS?1.3 post-handshake authentication requests can happen anytime, and thus clients need to be ready to deal with GNUTLS_E_REAUTH_REQUEST at any time. In particular, ?gnutls_record_recv? might return this error, and the client has to call ?gnutls_reauth? at that point. In the Guile bindings, GnuTLS errors are mapped to Guile exceptions. The record layer is mapped to an I/O port, which is the abstraction used for file contents, sockets, etc. (similar to FILE* in C). The problem here is that you could get a GNUTLS_E_REAUTH_REQUEST exception in the middle of a read from an I/O ports. This breaks abstraction because the caller of that read call may not know that the port happens to be a GnuTLS record port. Have other language bindings developers faced this issue? I?m thinking that we could ask users to set a GNUTLS_E_REAUTH_REQUEST handler beforehand such that, when we get GNUTLS_E_REAUTH_REQUEST, we directly call that handler instead of throwing an exception. Thoughts? Ludo?. From ametzler at bebt.de Sat Jun 8 11:29:39 2019 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 8 Jun 2019 11:29:39 +0200 Subject: [gnutls-help] 3.6.7 interoperability problems with earlier 3.6.x Message-ID: <20190608092939.GA1160@argenau.bebt.de> Hello, this is https://bugs.debian.org/929907 submitted and boiled down to a minimal (gnutls-cli) testcase by Dominik George. (The original issue was openldap breaking.) gnutls-serv from 3.6.4 3.6.5 and 3.6.6 does not work correctly with gnutls-cli from 3.6.7. ------ gnutls-serv --echo --x509keyfile /etc/ssl/private/ssl-cert-snakeoil.key --x509certfile /etc/ssl/certs/ssl-cert-snakeoil.pem ... pwgen 16383 | gnutls-cli --no-ca-verification --port 5556 localhost > From a size of 16383 bytes onwards, I get: > |<1>| Received packet with illegal length: 16385 > |<1>| Discarded message[1] due to invalid decryption > *** Fatal error: A TLS record packet with invalid length was received. > *** Server has terminated the connection abnormally. ------ gnutls-cli 3.6.8 works. Disabling TLS 1.3 or %NO_EXTENSIONS also works around this. I have run git bisect to find more info. The issue was introduced in 3fc7d37dd81a1f415afffbf5f733c13296e74824 ext/record_size_limit: account for content type octet in TLS 1.3 and was fixed for 3.6.8 by 2dc96e3b8d0e043bebf0815edaaa945f66ac0531 ext/record_size_limit: distinguish sending and receiving limits I am now wondering on what to do with this bug for the next Debian stable release ("buster"). * We are unlikely to upgrade to 3.6.8 since buster is already frozen. * Both reverting 3fc7d37dd81a1f415afffbf5f733c13296e74824 and applying 2dc96e3b8d0e043bebf0815edaaa945f66ac0531 makes the issue unreproducible. I don't like the former because it reverts a TLS 1.3 bugfix. Straightforward applying of the latter would add gnutls_record_set_max_recv_size(). (So I'd problably rename to _gnutls_record_set_max_recv_size and patch to not export.) * I am not sure about the impact, whether we are unlucky we don't have a failing testcase with openssl or whether it only shows up with Record Size Limit Extension. However Ubuntu Cosmic Cuttlefish and Disco Dingo ship 3.6.4 and 3.6.5 respectively, so we can't just ignore this, since I really want Debian and Ubuntu release to work together. ;-) * Do the git bisect result make sense? 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 buytenh at wantstofly.org Sat Jun 8 12:20:28 2019 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Sat, 8 Jun 2019 13:20:28 +0300 Subject: [gnutls-help] 3.6.7 interoperability problems with earlier 3.6.x In-Reply-To: <20190608092939.GA1160@argenau.bebt.de> References: <20190608092939.GA1160@argenau.bebt.de> Message-ID: <20190608102028.GB9017@wantstofly.org> On Sat, Jun 08, 2019 at 11:29:39AM +0200, Andreas Metzler wrote: > this is https://bugs.debian.org/929907 submitted and boiled down to a > minimal (gnutls-cli) testcase by Dominik George. (The original issue was > openldap breaking.) > > gnutls-serv from 3.6.4 3.6.5 and 3.6.6 does not work correctly with > gnutls-cli from 3.6.7. > ------ > gnutls-serv --echo --x509keyfile /etc/ssl/private/ssl-cert-snakeoil.key --x509certfile /etc/ssl/certs/ssl-cert-snakeoil.pem > ... > pwgen 16383 | gnutls-cli --no-ca-verification --port 5556 localhost > > From a size of 16383 bytes onwards, I get: > > > |<1>| Received packet with illegal length: 16385 > > |<1>| Discarded message[1] due to invalid decryption > > *** Fatal error: A TLS record packet with invalid length was received. > > *** Server has terminated the connection abnormally. > ------ > > gnutls-cli 3.6.8 works. Disabling TLS 1.3 or %NO_EXTENSIONS also works > around this. > > I have run git bisect to find more info. The issue was introduced in > 3fc7d37dd81a1f415afffbf5f733c13296e74824 > ext/record_size_limit: account for content type octet in TLS 1.3 > > and was fixed for 3.6.8 by > 2dc96e3b8d0e043bebf0815edaaa945f66ac0531 > ext/record_size_limit: distinguish sending and receiving limits > > I am now wondering on what to do with this bug for the next Debian > stable release ("buster"). > * We are unlikely to upgrade to 3.6.8 since buster is already frozen. > * Both reverting 3fc7d37dd81a1f415afffbf5f733c13296e74824 and applying > 2dc96e3b8d0e043bebf0815edaaa945f66ac0531 makes the issue > unreproducible. I don't like the former because it reverts a TLS 1.3 > bugfix. Straightforward applying of the latter would add > gnutls_record_set_max_recv_size(). (So I'd problably rename to > _gnutls_record_set_max_recv_size and patch to not export.) > * I am not sure about the impact, whether we are unlucky we don't have a > failing testcase with openssl or whether it only shows up with Record > Size Limit Extension. However Ubuntu Cosmic Cuttlefish and Disco Dingo > ship 3.6.4 and 3.6.5 respectively, so we can't just ignore this, since > I really want Debian and Ubuntu release to work together. ;-) > * Do the git bisect result make sense? (I have no useful insights concerning your bug to add, other than to remark that this sounds similar to an issue I ran into a while ago: https://lists.gnupg.org/pipermail/gnutls-help/2019-January/004472.html Apologies in case this is off-topic.) From ametzler at bebt.de Sat Jun 8 18:53:53 2019 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 8 Jun 2019 18:53:53 +0200 Subject: [gnutls-help] 3.6.7 interoperability problems with earlier 3.6.x In-Reply-To: <20190608092939.GA1160@argenau.bebt.de> References: <20190608092939.GA1160@argenau.bebt.de> Message-ID: <20190608165353.GB1160@argenau.bebt.de> On 2019-06-08 Andreas Metzler wrote: [...] > gnutls-serv from 3.6.4 3.6.5 and 3.6.6 does not work correctly with > gnutls-cli from 3.6.7. [...] > * Both reverting 3fc7d37dd81a1f415afffbf5f733c13296e74824 and applying > 2dc96e3b8d0e043bebf0815edaaa945f66ac0531 makes the issue > unreproducible. I don't like the former because it reverts a TLS 1.3 > bugfix. Straightforward applying of the latter would add > gnutls_record_set_max_recv_size(). [...] Actually addition of gnutls_record_set_max_recv_size() in this patchset is self-contained and trivial to strip out. From nmav at gnutls.org Sat Jun 8 19:32:09 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 8 Jun 2019 19:32:09 +0200 Subject: [gnutls-help] TLS 1.3 post-handshake authentication vs. exceptions In-Reply-To: <87d0jphd38.fsf@gnu.org> References: <87d0jphd38.fsf@gnu.org> Message-ID: On Fri, Jun 7, 2019 at 1:04 PM Ludovic Court?s wrote: > > Hello, > > AIUI, TLS 1.3 post-handshake authentication requests can happen anytime, > and thus clients need to be ready to deal with GNUTLS_E_REAUTH_REQUEST > at any time. In particular, ?gnutls_record_recv? might return this > error, and the client has to call ?gnutls_reauth? at that point. Right. A clarification, that these can happen only if the client or server has explicitly enabled post-handshake authentication with the corresponding gnutls_init() flag. > In the Guile bindings, GnuTLS errors are mapped to Guile exceptions. > The record layer is mapped to an I/O port, which is the abstraction used > for file contents, sockets, etc. (similar to FILE* in C). > > The problem here is that you could get a GNUTLS_E_REAUTH_REQUEST > exception in the middle of a read from an I/O ports. This breaks > abstraction because the caller of that read call may not know that the > port happens to be a GnuTLS record port. That should be similar to GNUTLS_E_REHANDSHAKE error. I'm not sure if that can be the right solution but there is the option of GNUTLS_AUTO_REAUTH. regards, Nikos From n.mavrogiannopoulos at gmail.com Sun Jun 9 06:35:34 2019 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sun, 09 Jun 2019 06:35:34 +0200 Subject: [gnutls-help] 3.6.7 interoperability problems with earlier 3.6.x In-Reply-To: <20190608092939.GA1160@argenau.bebt.de> References: <20190608092939.GA1160@argenau.bebt.de> Message-ID: On Sat, 2019-06-08 at 11:29 +0200, Andreas Metzler wrote: > Hello, > > this is https://bugs.debian.org/929907 submitted and boiled down to a > minimal (gnutls-cli) testcase by Dominik George. (The original issue > was > openldap breaking.) > > gnutls-serv from 3.6.4 3.6.5 and 3.6.6 does not work correctly with > gnutls-cli from 3.6.7. > ------ > gnutls-serv --echo --x509keyfile /etc/ssl/private/ssl-cert- > snakeoil.key --x509certfile /etc/ssl/certs/ssl-cert-snakeoil.pem > ... > pwgen 16383 | gnutls-cli --no-ca-verification --port 5556 localhost > > From a size of 16383 bytes onwards, I get: > > > <1>| Received packet with illegal length: 16385 > > > <1>| Discarded message[1] due to invalid decryption > > *** Fatal error: A TLS record packet with invalid length was > > received. > > *** Server has terminated the connection abnormally. > ------ > > gnutls-cli 3.6.8 works. Disabling TLS 1.3 or %NO_EXTENSIONS also > works > around this. > > I have run git bisect to find more info. The issue was introduced in > 3fc7d37dd81a1f415afffbf5f733c13296e74824 > ext/record_size_limit: account for content type octet in TLS 1.3 > > and was fixed for 3.6.8 by > 2dc96e3b8d0e043bebf0815edaaa945f66ac0531 > ext/record_size_limit: distinguish sending and receiving limits > > I am now wondering on what to do with this bug for the next Debian > stable release ("buster"). > * We are unlikely to upgrade to 3.6.8 since buster is already frozen. What is blocking the upgrade to 3.6.8? Is there some further change to do in the development rules so that debian can follow the stable branch? Having multiple gnutls versions in the major distributions with diverse behaviors would make things not easy in terms of interoperability for tls1.3 or any other future feature. regards, Nikos From ametzler at bebt.de Sun Jun 9 11:38:42 2019 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 9 Jun 2019 11:38:42 +0200 Subject: [gnutls-help] 3.6.7 interoperability problems with earlier 3.6.x In-Reply-To: References: <20190608092939.GA1160@argenau.bebt.de> Message-ID: <20190609093842.GB1450@argenau.bebt.de> On 2019-06-09 Nikos Mavrogiannopoulos wrote: > On Sat, 2019-06-08 at 11:29 +0200, Andreas Metzler wrote: [...] > > I am now wondering on what to do with this bug for the next Debian > > stable release ("buster"). > > * We are unlikely to upgrade to 3.6.8 since buster is already frozen. > What is blocking the upgrade to 3.6.8? Is there some further change to > do in the development rules so that debian can follow the stable > branch? Hello Nikos, the rules [1] for updates for the soon-to-be-released "buster" are very tight, every update is reviewed indiviually by an actual person. --------------- * targeted fixes for release critical bugs (i.e., bugs of severity critical, grave, and serious) in all packages; * fixes for severity: important bugs in packages of priority: optional, only when this can be done via unstable; * translation updates and documentation fixes that are included with fixes for the above criteria; [...] A targeted fix is one with only the minimum necessary changes to resolve a bug. --------------- (An important bug is defined as "a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone.") A GnuTLS release on the stable branch OTOH can contain a lot more than that (essentially everything that does not break the API.). Looking at commits in 3.6.8 we find a lot of stuff that would not do for a Debian stable/frozen update. * beautification 8e28bb311ab33a1e7886e46af167311534070c39 * New features (e.g AES-XTS) * cleanup (344c77b755f68370a098b90ef2ce981b829dd534 handshake: remove unnecessary HSK_CRT_SENT flag) * Improvements for the test-suite I do not think that this is really solvable. GnuTLS and Debian release time are just not aligned and are not alignable. It is a matter of scale. - Debian cannot start doing bi-monthly stable releases including feature upgrades and GnuTLS would not improve if it switched to bi-annual releases (all new features happening in the unstable branch which was almost untested). > Having multiple gnutls versions in the major distributions with > diverse behaviors would make things not easy in terms of > interoperability for tls1.3 or any other future feature. I think that is unavoidable. If you can think of specific changes in 3.6.8 that you think I should cherry-pick I would be very grateful. Perhaps #720 (IDNA)? TIA, cu Andreas [1] https://release.debian.org/buster/freeze_policy.html -- `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 Mon Jun 10 11:23:44 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 10 Jun 2019 11:23:44 +0200 Subject: [gnutls-help] 3.6.7 interoperability problems with earlier 3.6.x In-Reply-To: <20190609093842.GB1450@argenau.bebt.de> References: <20190608092939.GA1160@argenau.bebt.de> <20190609093842.GB1450@argenau.bebt.de> Message-ID: On Sun, Jun 9, 2019 at 11:39 AM Andreas Metzler wrote: > > On 2019-06-09 Nikos Mavrogiannopoulos wrote: > > On Sat, 2019-06-08 at 11:29 +0200, Andreas Metzler wrote: > [...] > > > I am now wondering on what to do with this bug for the next Debian > > > stable release ("buster"). > > > * We are unlikely to upgrade to 3.6.8 since buster is already frozen. > > > What is blocking the upgrade to 3.6.8? Is there some further change to > > do in the development rules so that debian can follow the stable > > branch? > > Hello Nikos, > > the rules [1] for updates for the soon-to-be-released "buster" are very > tight, every update is reviewed indiviually by an actual person. > --------------- > * targeted fixes for release critical bugs (i.e., bugs of severity > critical, grave, and serious) in all packages; > * fixes for severity: important bugs in packages of priority: optional, > only when this can be done via unstable; > * translation updates and documentation fixes that are included with > fixes for the above criteria; > [...] > A targeted fix is one with only the minimum necessary changes to resolve > a bug. > --------------- > > (An important bug is defined as "a bug which has a major effect on the > usability of a package, without rendering it completely unusable to > everyone.") > > A GnuTLS release on the stable branch OTOH can contain a lot more than > that (essentially everything that does not break the API.) I'd say break existing behavior (ABI or API). Thus the update may have new stuff, but none of these can break existing applications. > Looking at > commits in 3.6.8 we find a lot of stuff that would not do for a Debian > stable/frozen update. > * beautification 8e28bb311ab33a1e7886e46af167311534070c39 > * New features (e.g AES-XTS) > * cleanup (344c77b755f68370a098b90ef2ce981b829dd534 handshake: remove > unnecessary HSK_CRT_SENT flag) > * Improvements for the test-suite > > I do not think that this is really solvable. GnuTLS and Debian release > time are just not aligned and are not alignable. It is a matter of > scale. - Debian cannot start doing bi-monthly stable releases including > feature upgrades and GnuTLS would not improve if it switched to > bi-annual releases (all new features happening in the unstable branch > which was almost untested). Ok. > > Having multiple gnutls versions in the major distributions with > > diverse behaviors would make things not easy in terms of > > interoperability for tls1.3 or any other future feature. > > I think that is unavoidable. > > If you can think of specific changes in 3.6.8 that you think I should > cherry-pick I would be very grateful. Perhaps #720 (IDNA)? On the important bugs bucket I'd put the streebog fix, and the gnutls_srp_set_server_credentials_function fix for 8192 parameters. These two can cause serious issues to applications that use this functionality but which were tested with the new release of gnutls, but run on debian. The fix "Fixed bug preventing the use of gnutls_pubkey_verify_data2() and gnutls_pubkey_verify_hash2() with the GNUTLS_VERIFY_DISABLE_CA_SIGN flag (#754)", I think fits into the previous bucket as well though its impact may be lower (fewer applications using this flag). The "Apply STD3 ASCII rules in gnutls_idna_map() to prevent hostname/domain crafting via IDNA conversion (#720)" is a security hardening measure to prevent potential problematic hostnames. I'm not aware of any exploitation under TLS/PKIX, though that doesn't mean that it cannot. The "During Diffie-Hellman operations in TLS, verify that the peer's public key is on the right subgroup (y^q=1 mod p), when q is available (under TLS 1.3 and under earlier versions when RFC7919 parameters are used)." is another security hardening measure that is due to NIST requirements (there is no IETF guidance afaik) however it makes sense IMHO. regards, Nikos From ametzler at bebt.de Mon Jun 10 15:02:38 2019 From: ametzler at bebt.de (Andreas Metzler) Date: Mon, 10 Jun 2019 15:02:38 +0200 Subject: [gnutls-help] 3.6.7 interoperability problems with earlier 3.6.x In-Reply-To: References: <20190608092939.GA1160@argenau.bebt.de> <20190609093842.GB1450@argenau.bebt.de> Message-ID: <20190610130238.GA1385@argenau.bebt.de> On 2019-06-10 Nikos Mavrogiannopoulos wrote: > On Sun, Jun 9, 2019 at 11:39 AM Andreas Metzler wrote: [...] Hello Nikos, >> If you can think of specific changes in 3.6.8 that you think I should >> cherry-pick I would be very grateful. Perhaps #720 (IDNA)? > On the important bugs bucket I'd put the streebog fix, and the > gnutls_srp_set_server_credentials_function fix for 8192 parameters. > These two can cause serious issues to applications that use this > functionality but which were tested with the new release of gnutls, > but run on debian. That is c1441665abe761536b3ed67d36b12f2198be6b12 and 0bdca5d51f203cf414d645e75ac197e3fadfadc8. > The fix "Fixed bug preventing the use of gnutls_pubkey_verify_data2() > and gnutls_pubkey_verify_hash2() with the > GNUTLS_VERIFY_DISABLE_CA_SIGN flag (#754)", I think fits into the > previous bucket as well though its impact may be lower (fewer > applications using this flag). b1476abeb6f8b5046e6cd62724cdac241f71aa7b BTW: Afaict the respective test in the followup patch 1d3452d69670e28edfcaa232847036f600bbe1e8 is never run, tests/sign-verify-data-newapi.c tests/sign-verify-newapi.c does not seem to be referenced in any Makefile. > The "Apply STD3 ASCII rules in gnutls_idna_map() to prevent > hostname/domain crafting via IDNA conversion (#720)" is a security > hardening measure to prevent potential problematic hostnames. I'm not > aware of any exploitation under TLS/PKIX, though that doesn't mean > that it cannot. b697e948b6f66440ee1f15337dfc83b6816bd21a > The "During Diffie-Hellman operations in TLS, verify that the peer's > public key is on the right subgroup (y^q=1 mod p), when q is available > (under TLS 1.3 and under earlier versions when RFC7919 parameters > are used)." is another security hardening measure that is due to NIST > requirements (there is no IETF guidance afaik) however it makes sense > IMHO. That would be 2555412f8982ec0a1bbbf6b3c10a0330fe848820 to e07061b29a75ff94f0dbf85ec44f7ad6c04761fa? i.e. this would include addition of gnutls_dh_params_import_raw3() and gnutls_ffdhe_????_group_q? TIA, cu Andreas From nmav at gnutls.org Mon Jun 10 22:33:31 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 10 Jun 2019 22:33:31 +0200 Subject: [gnutls-help] 3.6.7 interoperability problems with earlier 3.6.x In-Reply-To: <20190610130238.GA1385@argenau.bebt.de> References: <20190608092939.GA1160@argenau.bebt.de> <20190609093842.GB1450@argenau.bebt.de> <20190610130238.GA1385@argenau.bebt.de> Message-ID: On Mon, Jun 10, 2019 at 3:03 PM Andreas Metzler wrote: > > On 2019-06-10 Nikos Mavrogiannopoulos wrote: > > On Sun, Jun 9, 2019 at 11:39 AM Andreas Metzler wrote: > [...] > > Hello Nikos, > > >> If you can think of specific changes in 3.6.8 that you think I should > >> cherry-pick I would be very grateful. Perhaps #720 (IDNA)? > > > On the important bugs bucket I'd put the streebog fix, and the > > gnutls_srp_set_server_credentials_function fix for 8192 parameters. > > These two can cause serious issues to applications that use this > > functionality but which were tested with the new release of gnutls, > > but run on debian. > > That is c1441665abe761536b3ed67d36b12f2198be6b12 and > 0bdca5d51f203cf414d645e75ac197e3fadfadc8. > > > The fix "Fixed bug preventing the use of gnutls_pubkey_verify_data2() > > and gnutls_pubkey_verify_hash2() with the > > GNUTLS_VERIFY_DISABLE_CA_SIGN flag (#754)", I think fits into the > > previous bucket as well though its impact may be lower (fewer > > applications using this flag). > > b1476abeb6f8b5046e6cd62724cdac241f71aa7b > > BTW: Afaict the respective test in the followup patch > 1d3452d69670e28edfcaa232847036f600bbe1e8 is never run, > tests/sign-verify-data-newapi.c tests/sign-verify-newapi.c does not seem > to be referenced in any Makefile. Thank you for that, a great catch. It seems that these tests were not run other than on their addition and did not catch a regression they intended to. I've proposed a fix for it: https://gitlab.com/gnutls/gnutls/merge_requests/1025 > > The "During Diffie-Hellman operations in TLS, verify that the peer's > > public key is on the right subgroup (y^q=1 mod p), when q is available > > (under TLS 1.3 and under earlier versions when RFC7919 parameters > > are used)." is another security hardening measure that is due to NIST > > requirements (there is no IETF guidance afaik) however it makes sense > > IMHO. > > That would be 2555412f8982ec0a1bbbf6b3c10a0330fe848820 to > e07061b29a75ff94f0dbf85ec44f7ad6c04761fa? i.e. this would include > addition of gnutls_dh_params_import_raw3() and gnutls_ffdhe_????_group_q? Yes. The new additions are mainly added to assist in testing. Maybe too extensive to backport. regards, Nikos From ludo at gnu.org Wed Jun 12 14:02:51 2019 From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=) Date: Wed, 12 Jun 2019 14:02:51 +0200 Subject: [gnutls-help] TLS 1.3 post-handshake authentication vs. exceptions In-Reply-To: (Nikos Mavrogiannopoulos's message of "Sat, 8 Jun 2019 19:32:09 +0200") References: <87d0jphd38.fsf@gnu.org> Message-ID: <87v9xbxb84.fsf@gnu.org> Hi, Nikos Mavrogiannopoulos skribis: > On Fri, Jun 7, 2019 at 1:04 PM Ludovic Court?s wrote: [...] >> The problem here is that you could get a GNUTLS_E_REAUTH_REQUEST >> exception in the middle of a read from an I/O ports. This breaks >> abstraction because the caller of that read call may not know that the >> port happens to be a GnuTLS record port. > > That should be similar to GNUTLS_E_REHANDSHAKE error. I'm not sure if > that can be the right solution but there is the option of > GNUTLS_AUTO_REAUTH. Indeed, GNUTLS_AUTO_REAUTH looks like a simple solution. Thanks! Ludo?. From oliver+gnutls-help at duckasylum.com Wed Jun 26 16:08:43 2019 From: oliver+gnutls-help at duckasylum.com (Oliver) Date: Wed, 26 Jun 2019 17:08:43 +0300 Subject: [gnutls-help] gnutls-3.6.8 build fail on RHEL 7.6 due to nettle_rsa_sec_decrypt In-Reply-To: References: Message-ID: <3c1df95bf06e12805a28908c8b6acfea@duckasylum.com> Hello My build (actually can't get past configure) of gnutls-3.6.8 on RHEL Server 7.6 (Maipo) fails with the following error: > checking for nettle_rsa_sec_decrypt... no > configure: error: Nettle lacks the required rsa_sec_decrypt function My configure parameters are the following: > ./configure --prefix /opt/gnutls-3.6.8 \ > CFLAGS="-I/opt/libunistring/include/ -I/opt/libidn2/include/ -I/opt/libnettle/include/" \ > LDFLAGS="-L/opt/libunistring/lib/ -L/opt/libidn2/lib/ -L/opt/libnettle/lib64/" \ > NETTLE_CFLAGS=-I/opt/libnettle/include/ \ > NETTLE_LIBS=-L/opt/libnettle/lib64/ \ > HOGWEED_CFLAGS=-I/opt/libnettle/include/ \ > HOGWEED_LIBS=-L/opt/libnettle/lib64/ \ > GMP_CFLAGS=-I/opt/gmp/include/ \ > GMP_LIBS=-L/opt/gmp/lib/ \ > LIBTASN1_CFLAGS=-I/opt/libtasn1/include/ \ > LIBTASN1_LIBS=-L/opt/libtasn1/lib/ \ > --with-libiconv-prefix=/opt/libiconv/ \ > --with-libintl-prefix=/opt/libintl/ \ > --enable-fips140-mode \ > --disable-non-suiteb-curves The thing is that when I run 'make check' in nettle source directory the rsa_sec_decrypt test passes. What am I doing wrong? I tested with both nettle 3.4.1 and 3.5 Links to config.log files: config log with nettle-3.4.1 [1] config log with nettle-3.5 [2] Thank You in advance, Oliver Links: ------ [1] https://1drv.ms/u/s!AsqaPT0ZS1sHgrVxwnwKBKa7BxvogA [2] https://1drv.ms/u/s!AsqaPT0ZS1sHgrVyFwC_g_ASItJ_MA -------------- next part -------------- An HTML attachment was scrubbed... URL: From ametzler at bebt.de Thu Jun 27 18:37:45 2019 From: ametzler at bebt.de (Andreas Metzler) Date: Thu, 27 Jun 2019 18:37:45 +0200 Subject: [gnutls-help] gnutls-3.6.8 build fail on RHEL 7.6 due to nettle_rsa_sec_decrypt In-Reply-To: <3c1df95bf06e12805a28908c8b6acfea@duckasylum.com> References: <3c1df95bf06e12805a28908c8b6acfea@duckasylum.com> Message-ID: <20190627163745.GB1620@argenau.bebt.de> On 2019-06-26 Oliver wrote: > Hello > My build (actually can't get past configure) of gnutls-3.6.8 on RHEL > Server 7.6 (Maipo) fails with the following error: > > checking for nettle_rsa_sec_decrypt... no > > configure: error: Nettle lacks the required rsa_sec_decrypt function > My configure parameters are the following: > > ./configure --prefix /opt/gnutls-3.6.8 \ > > CFLAGS="-I/opt/libunistring/include/ -I/opt/libidn2/include/ -I/opt/libnettle/include/" \ > > LDFLAGS="-L/opt/libunistring/lib/ -L/opt/libidn2/lib/ -L/opt/libnettle/lib64/" \ > > NETTLE_CFLAGS=-I/opt/libnettle/include/ \ > > NETTLE_LIBS=-L/opt/libnettle/lib64/ \ [...] > What am I doing wrong? I tested with both nettle 3.4.1 and 3.5 [...] Hello, Afaict you are telling ./configure that the following command will link foo against nettle cc foo.o -I/opt/libnettle/include/ -L/opt/libnettle/lib64 -o foo Which obviously is missing a -lnettle somewhere. 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'