bug#25060: gnutls: asynchronous spurious "fatal error"

[Ted Zlatanov]

On Wed, 25 Jan 2017 00:17:58 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Yes, it just means that the peer ended the connection.  I think gnutls.c
LI> shouldn't say anything in that case -- any sentinels get the proper
LI> callback and stuff, and as information it's pretty worthless for the
LI> user.

LI> I'm installing the following patch, but if there's any disagreement
LI> here, we can discuss further...

LI> diff --git a/src/gnutls.c b/src/gnutls.c
LI> index 735d2e3..6fa0e10 100644
LI> --- a/src/gnutls.c
LI> +++ b/src/gnutls.c
LI> @@ -582,8 +582,15 @@ emacs_gnutls_handle_error (gnutls_session_t session, 
int err)
 
LI>    if (gnutls_error_is_fatal (err))
LI>      {
LI> +      int level = 1;
LI> +      /* Mostly ignore "The TLS connection was non-properly
LI> +    terminated" message which just means that the peer closed the
LI> +    connection.  */
LI> +      if (err == GNUTLS_E_PREMATURE_TERMINATION)
LI> +   level = 3;
LI> +
LI> +      GNUTLS_LOG2 (level, max_log_level, "fatal error:", str);
LI>        ret = 0;
LI> -      GNUTLS_LOG2 (1, max_log_level, "fatal error:", str);
LI>      }
LI>    else
LI>      {

IIRC that #define wasn't available until recently so we couldn't use it
until now :) Thanks! It resolves the issue for me. We may want to add a
per-connection counter of these, though, in case code or users want to
examine it.

Ted