bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.

Paul Eggert
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




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.

Eli Zaretskii
> From: Paul Eggert <[hidden email]>
> Date: Sat, 15 Jul 2017 09:14:05 -0700
> Cc: Paul Eggert <[hidden email]>
>
> 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.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.

Ted Zlatanov
On Sat, 15 Jul 2017 19:33:40 +0300 Eli Zaretskii <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.

Eli Zaretskii
> From: Ted Zlatanov <[hidden email]>
> Cc: Paul Eggert <[hidden email]>,  [hidden email]
> Date: Sat, 15 Jul 2017 15:11:01 -0400
>
> On Sat, 15 Jul 2017 19:33:40 +0300 Eli Zaretskii <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.

Paul Eggert
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 :-).



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.

Eli Zaretskii
> Cc: [hidden email]
> From: Paul Eggert <[hidden email]>
> 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.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.

Paul Eggert
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).



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.

Eli Zaretskii
> Cc: [hidden email], [hidden email]
> From: Paul Eggert <[hidden email]>
> 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.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27708: [PROPOSED] Simplify configuration of HAVE_GNUTLS3 etc.

Ted Zlatanov
In reply to this post by Paul Eggert
On Sun, 16 Jul 2017 19:08:45 +0300 Eli Zaretskii <[hidden email]> 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




Loading...