GNU bug report logs - #27708
[PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 27708 in the body.
You can then email your comments to 27708 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: bug-gnu-emacs <at> gnu.org
Cc: Paul Eggert <eggert <at> cs.ucla.edu>
Subject: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Sat, 15 Jul 2017 09:14:05 -0700

There's only one GnuTLS, so configuring these symbols at
'configure' time is overkill.  Simplify things by moving their
configuration to src/gnutls.h.
* configure.ac (HAVE_GNUTLS3, HAVE_GNUTLS3_HMAC, HAVE_GNUTLS3_AEAD)
(HAVE_GNUTLS3_CIPHER, HAVE_GNUTLS3_DIGEST): Move these definitions
from here ...
* src/gnutls.h: ... to here, and simplify.
---
 configure.ac | 83 ------------------------------------------------------------
 src/gnutls.h | 12 +++++++--
 2 files changed, 10 insertions(+), 85 deletions(-)

diff --git a/configure.ac b/configure.ac
index 056c8c3..329a590 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2829,89 +2829,6 @@ AC_DEFUN
     [HAVE_GNUTLS=yes], [HAVE_GNUTLS=no])
   if test "${HAVE_GNUTLS}" = "yes"; then
     AC_DEFINE(HAVE_GNUTLS, 1, [Define if using GnuTLS.])
-    EMACS_CHECK_MODULES([LIBGNUTLS3], [gnutls >= 3.0.0],
-      [AC_DEFINE(HAVE_GNUTLS3, 1, [Define if using GnuTLS v3.])], [])
-
-    AC_CACHE_CHECK([for GnuTLS v3 with HMAC], [emacs_cv_gnutls3_hmac],
-      [AC_COMPILE_IFELSE(
-	[AC_LANG_PROGRAM([[
-	      #include <gnutls/gnutls.h>
-	      #include <gnutls/crypto.h>
-	   ]], [[
-	     int
-	     main (void)
-	     {
-	       gnutls_hmac_hd_t handle;
-	       gnutls_hmac_deinit (handle, NULL);
-	     }
-	   ]])],
-	[emacs_cv_gnutls3_hmac=yes],
-	[emacs_cv_gnutls3_hmac=no])])
-    if test "$emacs_cv_gnutls3_hmac" = yes; then
-      AC_DEFINE([HAVE_GNUTLS3_HMAC], [1],
-	[Define if using GnuTLS v3 with HMAC support.])
-    fi
-
-    AC_CACHE_CHECK([for GnuTLS v3 with AEAD], [emacs_cv_gnutls3_aead],
-      [AC_COMPILE_IFELSE(
-	[AC_LANG_PROGRAM([[
-	      #include <gnutls/gnutls.h>
-	      #include <gnutls/crypto.h>
-	   ]], [[
-	     int
-	     main (void)
-	     {
-	       gnutls_aead_cipher_hd_t handle;
-	       gnutls_aead_cipher_deinit (handle);
-	     }
-	   ]])],
-	[emacs_cv_gnutls3_aead=yes],
-	[emacs_cv_gnutls3_aead=no])])
-    if test "$emacs_cv_gnutls3_aead" = yes; then
-      AC_DEFINE([HAVE_GNUTLS3_AEAD], [1],
-	[Define if using GnuTLS v3 with AEAD support.])
-    fi
-
-    AC_CACHE_CHECK([for GnuTLS v3 with cipher], [emacs_cv_gnutls3_cipher],
-      [AC_COMPILE_IFELSE(
-	[AC_LANG_PROGRAM([[
-	      #include <gnutls/gnutls.h>
-	      #include <gnutls/crypto.h>
-	   ]], [[
-	     int
-	     main (void)
-	     {
-	       gnutls_cipher_hd_t handle;
-	       gnutls_cipher_encrypt2 (handle, NULL, 0, NULL, 0);
-	       gnutls_cipher_deinit (handle);
-	     }
-	   ]])],
-	[emacs_cv_gnutls3_cipher=yes],
-	[emacs_cv_gnutls3_cipher=no])])
-    if test "$emacs_cv_gnutls3_cipher" = yes; then
-      AC_DEFINE([HAVE_GNUTLS3_CIPHER], [1],
-	[Define if using GnuTLS v3 with cipher support.])
-    fi
-
-    AC_CACHE_CHECK([for GnuTLS v3 with digest], [emacs_cv_gnutls3_digest],
-      [AC_COMPILE_IFELSE(
-	[AC_LANG_PROGRAM([[
-	      #include <gnutls/gnutls.h>
-	      #include <gnutls/crypto.h>
-	   ]], [[
-	     int
-	     main (void)
-	     {
-	       gnutls_hash_hd_t handle;
-	       gnutls_hash_deinit (handle, NULL);
-	     }
-	   ]])],
-	[emacs_cv_gnutls3_digest=yes],
-	[emacs_cv_gnutls3_digest=no])])
-    if test "$emacs_cv_gnutls3_digest" = yes; then
-      AC_DEFINE([HAVE_GNUTLS3_DIGEST], [1],
-	[Define if using GnuTLS v3 with digest support.])
-    fi
   fi
 
   # Windows loads GnuTLS dynamically
diff --git a/src/gnutls.h b/src/gnutls.h
index 3ec86a8..19c1686 100644
--- a/src/gnutls.h
+++ b/src/gnutls.h
@@ -23,8 +23,16 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
 #include <gnutls/gnutls.h>
 #include <gnutls/x509.h>
 
-#ifdef HAVE_GNUTLS3
-#include <gnutls/crypto.h>
+#if 0x030000 <= GNUTLS_VERSION_NUMBER
+# define HAVE_GNUTLS3
+# include <gnutls/crypto.h>
+#endif
+
+#if 0x030400 <= GNUTLS_VERSION_NUMBER
+# define HAVE_GNUTLS3_AEAD
+# define HAVE_GNUTLS3_CIPHER
+# define HAVE_GNUTLS3_DIGEST
+# define HAVE_GNUTLS3_HMAC
 #endif
 
 #include "lisp.h"
-- 
2.7.4

Message #8 received at 27708 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 27708 <at> debbugs.gnu.org
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Sat, 15 Jul 2017 19:33:40 +0300

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 15 Jul 2017 09:14:05 -0700
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> diff --git a/src/gnutls.h b/src/gnutls.h
> index 3ec86a8..19c1686 100644
> --- a/src/gnutls.h
> +++ b/src/gnutls.h
> @@ -23,8 +23,16 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
>  #include <gnutls/gnutls.h>
>  #include <gnutls/x509.h>
>  
> -#ifdef HAVE_GNUTLS3
> -#include <gnutls/crypto.h>
> +#if 0x030000 <= GNUTLS_VERSION_NUMBER
> +# define HAVE_GNUTLS3
> +# include <gnutls/crypto.h>
> +#endif
> +
> +#if 0x030400 <= GNUTLS_VERSION_NUMBER
> +# define HAVE_GNUTLS3_AEAD
> +# define HAVE_GNUTLS3_CIPHER
> +# define HAVE_GNUTLS3_DIGEST
> +# define HAVE_GNUTLS3_HMAC
>  #endif

If we want to support the new APIs only starting with GnuTLS 3.4.0,
then this is a step in the right direction.  But is that the intent?
Most of the functions we need are available in much older versions,
and others since 3.2.0.  Only a few appeared in 3.4.0.  So it might
also make sense to make our code more fine-grained, not less, if we
want to make as many of these APIs available on as many platforms as
possible.

But I'm not sure what was Ted's intent, and what we want as a project.

Message #11 received at 27708 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 27708 <at> debbugs.gnu.org
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Sat, 15 Jul 2017 15:11:01 -0400

On Sat, 15 Jul 2017 19:33:40 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote: 

EZ> If we want to support the new APIs only starting with GnuTLS 3.4.0,
EZ> then this is a step in the right direction.  But is that the intent?
EZ> Most of the functions we need are available in much older versions,
EZ> and others since 3.2.0.  Only a few appeared in 3.4.0.  So it might
EZ> also make sense to make our code more fine-grained, not less, if we
EZ> want to make as many of these APIs available on as many platforms as
EZ> possible.

EZ> But I'm not sure what was Ted's intent, and what we want as a project.

Exactly, and I replied on emacs-devel in the same vein. I'd like to
ensure people on 3.2.x have as much functionality as possible because
they may not be able to upgrade quickly. I also worry about forward
compatibility with a future 4.x or later GnuTLS API. So I'd like
comments and votes on this.

A good starting point is
https://www.gnutls.org/manual/html_node/Cryptographic-API.html which
will show the ebb and flow of the API since the 2.x versions.

Ted

Message #14 received at 27708 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ted Zlatanov <tzz <at> lifelogs.com>
Cc: eggert <at> cs.ucla.edu, 27708 <at> debbugs.gnu.org
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Sat, 15 Jul 2017 22:22:14 +0300

> From: Ted Zlatanov <tzz <at> lifelogs.com>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>,  27708 <at> debbugs.gnu.org
> Date: Sat, 15 Jul 2017 15:11:01 -0400
> 
> On Sat, 15 Jul 2017 19:33:40 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote: 
> 
> EZ> If we want to support the new APIs only starting with GnuTLS 3.4.0,
> EZ> then this is a step in the right direction.  But is that the intent?
> EZ> Most of the functions we need are available in much older versions,
> EZ> and others since 3.2.0.  Only a few appeared in 3.4.0.  So it might
> EZ> also make sense to make our code more fine-grained, not less, if we
> EZ> want to make as many of these APIs available on as many platforms as
> EZ> possible.
> 
> EZ> But I'm not sure what was Ted's intent, and what we want as a project.
> 
> Exactly, and I replied on emacs-devel in the same vein. I'd like to
> ensure people on 3.2.x have as much functionality as possible because
> they may not be able to upgrade quickly.

I see your point, but in that case the code needs "more work", since
in quite a few places the Lisp primitives you wrote mix up functions
available in very old GnuTLS versions with one or two that are only
available in latest versions.  To be able to support older versions of
the library, we need graceful degradation, and that hasn't been coded.
All we can easily do with the current code is return nil instead of
useful information, but that doesn't strike me as "graceful".

> A good starting point is
> https://www.gnutls.org/manual/html_node/Cryptographic-API.html which
> will show the ebb and flow of the API since the 2.x versions.

Alas, the GnuTLS manual doesn't say for each function in what version
it was introduced, it does so only for some of them.

Message #17 received at 27708 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Ted Zlatanov <tzz <at> lifelogs.com>
Cc: 27708 <at> debbugs.gnu.org
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Sat, 15 Jul 2017 17:31:58 -0700

Eli Zaretskii wrote:
> the GnuTLS manual doesn't say for each function in what version
> it was introduced

The GnuTLS folks are pretty good about documenting API changes, it's just not in 
the main manual. For example:

http://www.gnutls.org/abi-tracker/timeline/gnutls/

I used that list, along with a copy of the GnuTLS development history, to come 
up with the version numbers in the proposed patch.  The patch should not change 
Emacs functionality at all: all it should do is simplify configuration (and make 
'configure' run a bit faster :-).

Message #20 received at 27708 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: tzz <at> lifelogs.com, 27708 <at> debbugs.gnu.org
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Sun, 16 Jul 2017 05:36:30 +0300

> Cc: 27708 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 15 Jul 2017 17:31:58 -0700
> 
> http://www.gnutls.org/abi-tracker/timeline/gnutls/
> 
> I used that list, along with a copy of the GnuTLS development history, to come 
> up with the version numbers in the proposed patch.  The patch should not change 
> Emacs functionality at all: all it should do is simplify configuration (and make 
> 'configure' run a bit faster :-).

I didn't say your patch changed any functionality.  I'm saying that if
we want to allow as many of these APIs to be useful on as many
platforms, we need to do more work on the code.

Message #23 received at 27708 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tzz <at> lifelogs.com, 27708 <at> debbugs.gnu.org
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Sun, 16 Jul 2017 08:18:57 -0700

Eli Zaretskii wrote:
> if
> we want to allow as many of these APIs to be useful on as many
> platforms, we need to do more work on the code.

One possible step forward is to use each of the APIs starting when they became 
available, as opposed to the current practice of using some of them only in 
GnuTLS v3 or later (even though they were available earlier). I could adjust my 
proposed patch to do that, if you like. Unlike my proposed patch, this would 
change Emacs behavior (but only on older GnuTLS platforms).

Message #26 received at 27708 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: tzz <at> lifelogs.com, 27708 <at> debbugs.gnu.org
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Sun, 16 Jul 2017 19:08:45 +0300

> Cc: tzz <at> lifelogs.com, 27708 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 16 Jul 2017 08:18:57 -0700
> 
> Eli Zaretskii wrote:
> > if
> > we want to allow as many of these APIs to be useful on as many
> > platforms, we need to do more work on the code.
> 
> One possible step forward is to use each of the APIs starting when they became 
> available, as opposed to the current practice of using some of them only in 
> GnuTLS v3 or later (even though they were available earlier). I could adjust my 
> proposed patch to do that, if you like. Unlike my proposed patch, this would 
> change Emacs behavior (but only on older GnuTLS platforms).

Yes, that's what I meant, but I think this won't be useful unless we
also introduce some fallbacks into the code which uses those new
functions.  AFAICT, it is the case in some of the new APIs that almost
all of the GnuTLS functions they use are available even before v3.X,
but then just one function they call needs 3.2.X or 3.4.X.  This makes
the entire API useless (it returns nil), which is a pity, since I'm
guessing we could code some workaround or maybe provide partial
functionality instead.  Alas, I don't know enough about these
functions to code such fallbacks.

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Mon, 17 Jul 2017 11:03:45 -0400

On Sun, 16 Jul 2017 19:08:45 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote: 

EZ> Yes, that's what I meant, but I think this won't be useful unless we
EZ> also introduce some fallbacks into the code which uses those new
EZ> functions.  AFAICT, it is the case in some of the new APIs that almost
EZ> all of the GnuTLS functions they use are available even before v3.X,
EZ> but then just one function they call needs 3.2.X or 3.4.X.  This makes
EZ> the entire API useless (it returns nil), which is a pity, since I'm
EZ> guessing we could code some workaround or maybe provide partial
EZ> functionality instead.  Alas, I don't know enough about these
EZ> functions to code such fallbacks.

I think the risk of providing broken or subtly insecure functionality is
bigger if we do workarounds. Also the maintenance effort will be lower
if we pin to specific versions instead of features. I'm inclined to take
Paul's advice on this since he knows this area so well.

Another point is that I'd rather not support GnuTLS 2.x for the new
functionality; 2.12 is deprecated and won't get new updates according to
https://lists.gnupg.org/pipermail/gnutls-devel/2016-November/008220.html
so we should make an effort not to rely on it. I'd even recommend
dropping 2.x support altogether in Emacs 26.

So maybe Paul's approach was best after all :)

Ted

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: bug-gnu-emacs <at> gnu.org
Cc: Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Thu, 27 Jul 2017 00:04:54 +0300

On Mon, 17 Jul 2017 11:03:45 -0400 Ted Zlatanov <tzz <at> lifelogs.com> wrote: 

TZ> So maybe Paul's approach was best after all :)

Paul, do you want to use your original patch as we discussed?

Ted

Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ted Zlatanov <tzz <at> lifelogs.com>, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Wed, 26 Jul 2017 16:23:30 -0700

Ted Zlatanov wrote:
> Paul, do you want to use your original patch as we discussed?

I'd prefer that, yes. It's not a big deal.

Message #38 received at 27708 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 27708 <at> debbugs.gnu.org
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Fri, 28 Jul 2017 00:11:43 +0300

On Wed, 26 Jul 2017 16:23:30 -0700 Paul Eggert <eggert <at> cs.ucla.edu> wrote: 

PE> Ted Zlatanov wrote:
>> Paul, do you want to use your original patch as we discussed?

PE> I'd prefer that, yes. It's not a big deal.

Great. Would you like to apply it?

Ted

Message #43 received at 27708-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ted Zlatanov <tzz <at> lifelogs.com>
Cc: 27708-done <at> debbugs.gnu.org
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Wed, 2 Aug 2017 19:50:14 -0700

Ted Zlatanov wrote:
> Would you like to apply it?

Sure, done, and closing this bug report.

Message #46 received at 27708 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 27708 <at> debbugs.gnu.org
Cc: eggert <at> cs.ucla.edu
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Thu, 03 Aug 2017 12:06:30 -0400

This causes a test failure in test-gnutls-000-availability.
https://hydra.nixos.org/build/57926906

(Reproduced on rhel7 with gnutls-3.3.24.)

Message #49 received at 27708 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 27708 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Thu, 03 Aug 2017 16:20:12 -0400

On Thu, 03 Aug 2017 12:06:30 -0400 Glenn Morris <rgm <at> gnu.org> wrote: 

GM> This causes a test failure in test-gnutls-000-availability.
GM> https://hydra.nixos.org/build/57926906

GM> (Reproduced on rhel7 with gnutls-3.3.24.)

I think that this means that one of MD5, SHA1, SHA224, SHA256, SHA384,
or SHA512 (the `secure-hash-algorithms' members currently) are not in
that version of GnuTLS.

That is not really necessary. I was overzealous writing the tests; we
can just test the `secure-hash-algorithms' that are in GnuTLS. Can we
check the patch below against Hydra without pushing it to master yet?

(I'm having a strange problem building Emacs as of this morning, so I
haven't been able to test the patch fully. Sorry.)

Thanks
Ted

diff --git a/test/lisp/net/gnutls-tests.el b/test/lisp/net/gnutls-tests.el
index 9dbb6c05b9..94dcb6c4ce 100644
--- a/test/lisp/net/gnutls-tests.el
+++ b/test/lisp/net/gnutls-tests.el
@@ -41,8 +41,10 @@ gnutls-tests-hexstring-equal
   (and (stringp a) (stringp b) (string-equal (encode-hex-string a) (encode-hex-string b))))

 (defvar gnutls-tests-internal-macs-upcased
-  (mapcar (lambda (sym) (cons sym (intern (upcase (symbol-name sym)))))
-          (secure-hash-algorithms)))
+  (cl-intersection
+   (mapcar (lambda (sym) (cons sym (intern (upcase (symbol-name sym)))))
+           (secure-hash-algorithms))
+   (mapcar 'car (gnutls-macs))))

 (defvar gnutls-tests-tested-macs
   (when (gnutls-available-p)

Message #52 received at 27708 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ted Zlatanov <tzz <at> lifelogs.com>, Glenn Morris <rgm <at> gnu.org>
Cc: 27708 <at> debbugs.gnu.org
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Thu, 3 Aug 2017 13:31:33 -0700

On 08/03/2017 01:20 PM, Ted Zlatanov wrote:
> I was overzealous writing the tests; we
> can just test the `secure-hash-algorithms' that are in GnuTLS. Can we
> check the patch below against Hydra without pushing it to master yet?

I tried that patch on my own copy (on Fedora 26, with GnuTLS 3.5.14) and 
it failed as noted at the end of this email.

> I'm having a strange problem building Emacs as of this morning, so I
> haven't been able to test the patch
What problem is it? Some of the recent changes probably suggest a 'make 
bootstrap', so I'd try that first.

Here's the failure I got:

Running 7 tests (2017-08-03 13:24:54-0700)
Test test-gnutls-000-availability backtrace:
  signal(ert-test-failed (((should (> (length gnutls-tests-internal-ma
  ert-fail(((should (> (length gnutls-tests-internal-macs-upcased) 5))
  (if (unwind-protect (setq value-7 (apply fn-5 args-6)) (setq form-de
  (let (form-description-9) (if (unwind-protect (setq value-7 (apply f
  (let ((value-7 'ert-form-evaluation-aborted-8)) (let (form-descripti
  (let ((fn-5 (function >)) (args-6 (list (length gnutls-tests-interna
  (lambda nil (let ((fn-0 (function memq)) (args-1 (list 'gnutls3 (gnu
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name test-gnutls-000-availability :documen
  ert-run-or-rerun-test(#s(ert--stats :selector (not (tag :expensive-t
  ert-run-tests((not (tag :expensive-test)) #f(compiled-function (even
  ert-run-tests-batch((not (tag :expensive-test)))
  ert-run-tests-batch-and-exit((not (tag :expensive-test)))
  eval((ert-run-tests-batch-and-exit '(not (tag :expensive-test))))
  command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/net/gnutls-tests.el"
  command-line()
  normal-top-level()
Test test-gnutls-000-availability condition:
    (ert-test-failed
     ((should
       (>
    (length gnutls-tests-internal-macs-upcased)
    5))
      :form
      (> 0 5)
      :value nil))
   FAILED  1/7  test-gnutls-000-availability

Message #55 received at 27708 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Glenn Morris <rgm <at> gnu.org>, 27708 <at> debbugs.gnu.org
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Thu, 03 Aug 2017 16:45:03 -0400

On Thu, 3 Aug 2017 13:31:33 -0700 Paul Eggert <eggert <at> cs.ucla.edu> wrote: 

PE> On 08/03/2017 01:20 PM, Ted Zlatanov wrote:
>> I was overzealous writing the tests; we
>> can just test the `secure-hash-algorithms' that are in GnuTLS. Can we
>> check the patch below against Hydra without pushing it to master yet?

PE> I tried that patch on my own copy (on Fedora 26, with GnuTLS 3.5.14) and it
PE> failed as noted at the end of this email.

That's a new error from the last one; we need to also drop the expected
number of MACs, removing this line:

-  (should (> (length gnutls-tests-internal-macs-upcased) 5))

>> I'm having a strange problem building Emacs as of this morning, so I
>> haven't been able to test the patch
PE> What problem is it? Some of the recent changes probably suggest a 'make
PE> bootstrap', so I'd try that first.

It's a renaming error. I posted on emacs-devel since it may be specific
to my setup. I'll try again later today or tomorrow. Thanks!

Ted

Message #58 received at 27708 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 27708 <at> debbugs.gnu.org
Cc: eggert <at> cs.ucla.edu
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Thu, 03 Aug 2017 17:32:59 -0400

Ted Zlatanov wrote:

> I think that this means that one of MD5, SHA1, SHA224, SHA256, SHA384,
> or SHA512 (the `secure-hash-algorithms' members currently) are not in
> that version of GnuTLS.
>
> That is not really necessary. I was overzealous writing the tests; we
> can just test the `secure-hash-algorithms' that are in GnuTLS.

Before a8a81df:

(mapcar 'car (gnutls-ciphers))

-> 
(RC2-40 ARCFOUR-40 DES-CBC 3DES-CBC CAMELLIA-256-GCM CAMELLIA-128-GCM
CAMELLIA-128-CBC CAMELLIA-192-CBC CAMELLIA-256-CBC SALSA20-256
ESTREAM-SALSA20-256 ARCFOUR-128 AES-256-GCM AES-128-GCM AES-128-CBC
AES-192-CBC AES-256-CBC)

After a8a81df:

(gnutls-ciphers) -> nil

which seems a pretty drastic change to me.

Again, this is with:
#define GNUTLS_VERSION "3.3.24"
#define GNUTLS_VERSION_NUMBER 0x030318

Message #61 received at 27708 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Glenn Morris <rgm <at> gnu.org>, 27708 <at> debbugs.gnu.org
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Thu, 3 Aug 2017 18:41:57 -0700

[Message part 1 (text/plain, inline)]

Glenn Morris wrote:
> After a8a81df:
> 
> (gnutls-ciphers) -> nil
> 
> which seems a pretty drastic change to me.

Yes, sorry, that wasn't intended. I installed the attached to try to fix that.

[0001-Fix-version-numbers-for-some-GnuTLS-features.patch (text/x-patch, attachment)]

Message #64 received at 27708 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Glenn Morris <rgm <at> gnu.org>, 27708 <at> debbugs.gnu.org
Subject: Re: bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.
Date: Fri, 04 Aug 2017 09:32:35 -0400

On Thu, 3 Aug 2017 18:41:57 -0700 Paul Eggert <eggert <at> cs.ucla.edu> wrote: 

PE> Glenn Morris wrote:
>> After a8a81df:
>> 
>> (gnutls-ciphers) -> nil
>> 
>> which seems a pretty drastic change to me.

PE> Yes, sorry, that wasn't intended. I installed the attached to try to fix that.

Hi Glenn,

looking at https://hydra.nixos.org/jobset/gnu/emacs-trunk it seems that
Paul's fix has resolved the GnuTLS tests without any patching of
gnutls-tests.el as I thought was needed. Can you confirm?

Thanks
Ted

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.