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

[Eli Zaretskii]

Ping!

Ted, I'd like to solve this one way or the other.  We have the data,
so the onus is now on us to act on it.

Thanks.

> Date: Fri, 25 Oct 2013 21:37:14 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs@kosowsky.org, 15648@debbugs.gnu.org
> 
> > 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?
> 
> 
> 
>