all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Andy Moreton <andrewjmoreton@gmail.com>
Cc: 31946@debbugs.gnu.org
Subject: bug#31946: 27.0.50; The NSM should warn about more TLS problems
Date: Tue, 27 Aug 2019 10:23:55 +0300	[thread overview]
Message-ID: <83tva3dqb8.fsf@gnu.org> (raw)
In-Reply-To: <86d0grfse1.fsf@gmail.com> (message from Andy Moreton on Mon, 26 Aug 2019 23:56:06 +0100)

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Mon, 26 Aug 2019 23:56:06 +0100
> 
> > Looks like something is wrong with how I'm using gnutls_free when it
> > comes from the DLL.  I need to look into that.
> 
> Found it I think. gnutls_free is a pointer of type gnutls_free_function,
> so the value returned from GetProcAddress is a data pointer, not a
> function address. Something like the following patch appears to work
> i.e. no longer crashes with the recipe above.

Yes, thanks.  I was struggling with the same thing, but evidently
there's a limit to what I can do after 11PM at my age ;-)

> If this is the right fix then we will need to add e.g. DEF_DLL_DATA and
> LOAD_DLL_DATA macros for runtime import of data (and an equivalent to
> get_proc_addr to use the right types for runtime data imports).

I think there's no need to invent harness for a single user, we can
simply do that by hand.  Please try the patch below, it's against the
current master (it also removes the unnecessary intermediate buffer
allocation while at that).

> The patch also has "#undef gnutls_free" because gnutls.h also defines
> gnutls_free as a macro, if GNUTLS_INTERNAL_BUILD is defined. For some
> reason the MSYS2 maintainers add a patch to their build to define
> GNUTLS_INTERNAL_BUILD unconditionally: see 0001-add-missing-define.patch
> at <https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-gnutls>.

I guess they want for some reason not to have the exported functions
decorated with __declspec(dllimport).  I have no idea why, maybe for
reasons of function visibility?  It's worth asking them, I think,
because this kind of kludge can be a nuisance.

diff --git a/src/gnutls.c b/src/gnutls.c
index 67d1fb9..fb75eb9 100644
--- a/src/gnutls.c
+++ b/src/gnutls.c
@@ -140,7 +140,6 @@ DEF_DLL_FN (void, gnutls_dh_set_prime_bits,
 DEF_DLL_FN (int, gnutls_dh_get_prime_bits, (gnutls_session_t));
 DEF_DLL_FN (int, gnutls_error_is_fatal, (int));
 DEF_DLL_FN (int, gnutls_global_init, (void));
-DEF_DLL_FN (void, gnutls_free, (void *));
 DEF_DLL_FN (void, gnutls_global_set_log_function, (gnutls_log_func));
 #  ifdef HAVE_GNUTLS3
 DEF_DLL_FN (void, gnutls_global_set_audit_log_function, (gnutls_audit_log_func));
@@ -291,6 +290,7 @@ DEF_DLL_FN (const char *, gnutls_ext_get_name, (unsigned int));
 #   endif
 #  endif	 /* HAVE_GNUTLS3 */
 
+static gnutls_free_function *gnutls_free_func;
 
 static bool
 init_gnutls_functions (void)
@@ -327,7 +327,6 @@ init_gnutls_functions (void)
   LOAD_DLL_FN (library, gnutls_dh_get_prime_bits);
   LOAD_DLL_FN (library, gnutls_error_is_fatal);
   LOAD_DLL_FN (library, gnutls_global_init);
-  LOAD_DLL_FN (library, gnutls_free);
   LOAD_DLL_FN (library, gnutls_global_set_log_function);
 #  ifdef HAVE_GNUTLS3
   LOAD_DLL_FN (library, gnutls_global_set_audit_log_function);
@@ -430,6 +429,13 @@ init_gnutls_functions (void)
 #   endif
 #  endif	 /* HAVE_GNUTLS3 */
 
+  /* gnutls_free is a variable inside GnuTLS, whose value is the
+     "free" function.  So it needs special handling.  */
+  gnutls_free_func = (gnutls_free_function *) GetProcAddress (library,
+							      "gnutls_free");
+  if (!gnutls_free_func)
+    return false;
+
   max_log_level = clip_to_bounds (INT_MIN, global_gnutls_log_level, INT_MAX);
   {
     Lisp_Object name = CAR_SAFE (Fget (Qgnutls, QCloaded_from));
@@ -465,7 +471,6 @@ init_gnutls_functions (void)
 #  define gnutls_global_init fn_gnutls_global_init
 #  define gnutls_global_set_audit_log_function fn_gnutls_global_set_audit_log_function
 #  define gnutls_global_set_log_function fn_gnutls_global_set_log_function
-#  define gnutls_free fn_gnutls_free
 #  define gnutls_global_set_log_level fn_gnutls_global_set_log_level
 #  define gnutls_handshake fn_gnutls_handshake
 #  define gnutls_init fn_gnutls_init
@@ -562,6 +567,11 @@ init_gnutls_functions (void)
 #   endif
 #  endif	 /* HAVE_GNUTLS3 */
 
+/* gnutls_free is a data pointer to a variable which holds a pointer
+   to the function.  We use #undef because MinGW64 defines gnutls_free
+   as a macro as well in the GnuTLS headers.  */
+#  undef gnutls_free
+#  define gnutls_free (*gnutls_free_func)
 
 /* This wrapper is called from fns.c, which doesn't know about the
    LOAD_DLL_FN stuff above.  */
@@ -1612,16 +1622,10 @@ DEFUN ("gnutls-format-certificate", Fgnutls_format_certificate,
 	     emacs_gnutls_strerror (err));
     }
 
-  char *out_buf = xmalloc ((out.size + 1) * sizeof (char));
-  memset (out_buf, 0, (out.size + 1) * sizeof (char));
-  memcpy (out_buf, out.data, out.size);
-
+  Lisp_Object result = make_string_from_bytes (out.data, out.size, out.size);
   gnutls_free (out.data);
   gnutls_x509_crt_deinit (crt);
 
-  Lisp_Object result = build_string (out_buf);
-  xfree (out_buf);
-
   return result;
 }
 





  reply	other threads:[~2019-08-27  7:23 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-23 10:38 bug#31946: 27.0.50; The NSM should warn about more TLS problems Lars Ingebrigtsen
2018-06-24 13:43 ` Lars Ingebrigtsen
2018-06-26  1:23 ` Noam Postavsky
2018-06-26  4:11   ` Jimmy Yuen Ho Wong
2018-06-26  6:26     ` Jimmy Yuen Ho Wong
2018-06-26 12:44       ` Noam Postavsky
2018-06-26 14:38       ` Eli Zaretskii
2018-07-03 15:08       ` Lars Ingebrigtsen
2018-07-04  1:34         ` Noam Postavsky
2018-07-08 14:20           ` Lars Ingebrigtsen
2018-07-08 14:21           ` Lars Ingebrigtsen
2018-07-08 14:22           ` Lars Ingebrigtsen
2018-07-08 18:34             ` Lars Ingebrigtsen
2018-07-08 18:50               ` Noam Postavsky
2018-07-08 20:01                 ` Lars Ingebrigtsen
2018-07-10  2:04                   ` Noam Postavsky
2018-07-22 11:05                     ` Lars Ingebrigtsen
2018-07-29 14:45                       ` Noam Postavsky
2018-07-08 18:36             ` Lars Ingebrigtsen
2018-07-08 19:20               ` Lars Ingebrigtsen
2018-07-08 14:23           ` Lars Ingebrigtsen
2018-06-26  9:27   ` Lars Ingebrigtsen
2018-06-26 14:42     ` Eli Zaretskii
2018-06-27  0:45       ` Noam Postavsky
2018-06-27  5:09         ` Jimmy Yuen Ho Wong
2018-06-27 12:07           ` Lars Ingebrigtsen
2018-06-27 12:20             ` Lars Ingebrigtsen
2018-06-27 15:16               ` Eli Zaretskii
2018-06-27 16:40                 ` Jimmy Yuen Ho Wong
2018-06-28 16:10                 ` Lars Ingebrigtsen
2018-06-28  0:14           ` Noam Postavsky
2018-06-28 15:58             ` Jimmy Yuen Ho Wong
2018-06-28 16:15               ` Lars Ingebrigtsen
2018-06-28 16:42                 ` Jimmy Yuen Ho Wong
2018-06-28 17:01                   ` Lars Ingebrigtsen
2018-06-28 18:15                     ` Jimmy Yuen Ho Wong
2018-06-29  5:21                       ` Jimmy Yuen Ho Wong
2018-06-29  5:25                         ` Jimmy Yuen Ho Wong
2018-06-30 17:28                           ` Jimmy Yuen Ho Wong
2018-06-30 20:30                             ` Noam Postavsky
2018-06-30 23:15                               ` Jimmy Yuen Ho Wong
2018-06-30 23:35                                 ` Noam Postavsky
2018-07-01 15:01                             ` Eli Zaretskii
2019-08-26  4:34 ` Lars Ingebrigtsen
2019-08-26 13:13   ` Andy Moreton
2019-08-26 16:07     ` Eli Zaretskii
2019-08-26 17:45       ` Andy Moreton
2019-08-26 18:12         ` Eli Zaretskii
2019-08-26 18:19           ` Andy Moreton
2019-08-26 19:36             ` Eli Zaretskii
2019-08-26 22:56               ` Andy Moreton
2019-08-27  7:23                 ` Eli Zaretskii [this message]
2019-08-27 15:25                   ` Andy Moreton
2019-08-27 15:50                     ` Eli Zaretskii
2019-08-27  8:01 ` bug#31946: 27.0.50; GnuTLS still crashes on MinGW Markus Weber
2019-08-27 15:00   ` Eli Zaretskii
2019-08-27 15:50     ` Eli Zaretskii
2019-08-29  8:05       ` mw
2019-08-29 12:20         ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83tva3dqb8.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=31946@debbugs.gnu.org \
    --cc=andrewjmoreton@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.