From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to crash completely Date: Sun, 03 Nov 2013 19:30:05 +0200 Message-ID: <83habt9yw2.fsf@gnu.org> References: <21089.32240.198931.971000@consult.pretender> <87fvrun1pw.fsf@flea.lifelogs.com> <21093.32992.278229.646703@consult.pretender> <877gd5mo5x.fsf@flea.lifelogs.com> <21094.39055.449629.706850@consult.pretender> <21094.40085.664080.69561@consult.pretender> <21094.52645.645440.977584@consult.pretender> <21094.64459.131668.849138@consult.pretender> <21095.19949.639350.970770@consult.pretender> <83wql4hvam.fsf@gnu.org> <21096.920.835718.562924@consult.pretender> <83hac7j2a2.fsf@gnu.org> <21097.58066.940940.323995@consult.pretender> <83iowlh27q.fsf@gnu.org> <87eh79ico2.fsf_-_@flea.lifelogs.com> <83a9hxgpt1.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1383499873 430 80.91.229.3 (3 Nov 2013 17:31:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Nov 2013 17:31:13 +0000 (UTC) Cc: emacs@kosowsky.org, 15648@debbugs.gnu.org To: tzz@lifelogs.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 03 18:31:17 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vd1W8-0003BV-8N for geb-bug-gnu-emacs@m.gmane.org; Sun, 03 Nov 2013 18:31:16 +0100 Original-Received: from localhost ([::1]:45895 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vd1W7-0007A7-Rl for geb-bug-gnu-emacs@m.gmane.org; Sun, 03 Nov 2013 12:31:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41818) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vd1W0-00079i-2r for bug-gnu-emacs@gnu.org; Sun, 03 Nov 2013 12:31:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vd1Vu-0002Vf-Pw for bug-gnu-emacs@gnu.org; Sun, 03 Nov 2013 12:31:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47068) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vd1Vu-0002VY-Dz for bug-gnu-emacs@gnu.org; Sun, 03 Nov 2013 12:31:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Vd1Vu-0004FI-1o for bug-gnu-emacs@gnu.org; Sun, 03 Nov 2013 12:31:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 Nov 2013 17:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15648 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15648-submit@debbugs.gnu.org id=B15648.138349982516274 (code B ref 15648); Sun, 03 Nov 2013 17:31:01 +0000 Original-Received: (at 15648) by debbugs.gnu.org; 3 Nov 2013 17:30:25 +0000 Original-Received: from localhost ([127.0.0.1]:32854 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vd1VH-0004EP-Ko for submit@debbugs.gnu.org; Sun, 03 Nov 2013 12:30:24 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:35812) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vd1VD-0004E8-Ga for 15648@debbugs.gnu.org; Sun, 03 Nov 2013 12:30:21 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MVP00800751B800@a-mtaout20.012.net.il> for 15648@debbugs.gnu.org; Sun, 03 Nov 2013 19:30:12 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MVP0073U7ABVSG0@a-mtaout20.012.net.il>; Sun, 03 Nov 2013 19:30:12 +0200 (IST) In-reply-to: <83a9hxgpt1.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:79919 Archived-At: 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 > Cc: emacs@kosowsky.org, 15648@debbugs.gnu.org > > > From: Ted Zlatanov > > 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? > > > >