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: Fri, 25 Oct 2013 21:37:14 +0300 Message-ID: <83a9hxgpt1.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1382726356 19720 80.91.229.3 (25 Oct 2013 18:39:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Oct 2013 18:39:16 +0000 (UTC) Cc: emacs@kosowsky.org, 15648@debbugs.gnu.org To: Ted Zlatanov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 25 20:39: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 1VZmHz-00035m-UN for geb-bug-gnu-emacs@m.gmane.org; Fri, 25 Oct 2013 20:39:16 +0200 Original-Received: from localhost ([::1]:60417 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZmHz-0003L2-Ho for geb-bug-gnu-emacs@m.gmane.org; Fri, 25 Oct 2013 14:39:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZmHr-0003Ju-4s for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 14:39:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZmHm-00059t-AZ for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 14:39:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58108) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZmHm-00059n-6g for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 14:39:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VZmHl-0007aS-Ts for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 14:39:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Oct 2013 18:39: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.138272630529082 (code B ref 15648); Fri, 25 Oct 2013 18:39:01 +0000 Original-Received: (at 15648) by debbugs.gnu.org; 25 Oct 2013 18:38:25 +0000 Original-Received: from localhost ([127.0.0.1]:43893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZmHA-0007Yz-3p for submit@debbugs.gnu.org; Fri, 25 Oct 2013 14:38:24 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:40431) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZmH5-0007Yk-U8 for 15648@debbugs.gnu.org; Fri, 25 Oct 2013 14:38:20 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MV800300MCQ9S00@a-mtaout22.012.net.il> for 15648@debbugs.gnu.org; Fri, 25 Oct 2013 21:37:28 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MV8003HKMEB4K40@a-mtaout22.012.net.il>; Fri, 25 Oct 2013 21:37:23 +0300 (IDT) In-reply-to: <87eh79ico2.fsf_-_@flea.lifelogs.com> 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:79656 Archived-At: > 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?