bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to


From: Eli Zaretskii
Subject: bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to crash completely
Date: Fri, 25 Oct 2013 21:37:14 +0300

> From: Ted Zlatanov <tzz@lifelogs.com>
> Cc: emacs@kosowsky.org,  15648@debbugs.gnu.org
> Date: Fri, 25 Oct 2013 11:38:05 -0400
> 
> EZ> If so, perhaps the problem is that we leave the process object
> EZ> marked as a GnuTLS process, but with a NULL state?  Should we remove
> EZ> the mark, or maybe delete the process object in gnutls-negotiate?
> 
> I would abort with a message like any other error.

Maybe you should install a change that does that, and see if it solves
the problem.

> Here's what we do:
> 
>         if (STRINGP (trustfile))
>           {
>             GNUTLS_LOG2 (1, max_log_level, "setting the trustfile: ",
>                          SSDATA (trustfile));
>             ret = fn_gnutls_certificate_set_x509_trust_file
>               (x509_cred,
>                SSDATA (trustfile),
>                file_format);
> 
>             if (ret < GNUTLS_E_SUCCESS)
>               return gnutls_make_error (ret);
>           }
>         else
>           {
>             emacs_gnutls_deinit (proc);
>             error ("Invalid trustfile");
>           }
> 
> In other words, we pass the file down and assume the return code from
> `fn_gnutls_certificate_set_x509_trust_file' will be accurate.  In this
> case I don't know what it returned but would assume GNUTLS_E_SUCCESS
> since there was no error.
> 
> In general I trust the return codes and don't verify the state
> explicitly.  I don't see how the `gnutls_state' could have been set to
> NULL by a missing trustfile; the function call that sets the trustfile
> only touches the `x509_cred' variable.  Could this NULL be happening
> later?

We _begin_ by setting gnutls_state to NULL.  What could possibly
happen is that we somehow let the process object with a NULL state
escape from the initialization step, and then
wait_reading_process_output stumbles on it and tries to use it,
because the gnutls_p flag is also set right at the beginning.

How about if we set the gnutls_p flag only when the whole
initialization succeeds completely?  It's only then that the process
is ready to be used in conjunction with GnuTLS, isn't it?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]