From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov 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 11:38:05 -0400 Organization: =?UTF-8?Q?=D0=A2=D0=B5=D0=BE=D0=B4=D0=BE=D1=80_?= =?UTF-8?Q?=D0=97=D0=BB=D0=B0=D1=82=D0=B0=D0=BD=D0=BE=D0=B2?= @ Cienfuegos Message-ID: <87eh79ico2.fsf_-_@flea.lifelogs.com> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1382715495 31974 80.91.229.3 (25 Oct 2013 15:38:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Oct 2013 15:38:15 +0000 (UTC) Cc: emacs@kosowsky.org, 15648@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 25 17:38: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 1VZjSq-0000WO-Vm for geb-bug-gnu-emacs@m.gmane.org; Fri, 25 Oct 2013 17:38:17 +0200 Original-Received: from localhost ([::1]:59775 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZjSq-0005nF-I9 for geb-bug-gnu-emacs@m.gmane.org; Fri, 25 Oct 2013 11:38:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55800) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZjSi-0005mF-8m for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 11:38:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZjSd-0003HI-4A for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 11:38:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57848) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZjSd-0003HD-0P for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 11:38:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VZjSc-0001TS-GO for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 11:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ted Zlatanov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Oct 2013 15:38:02 +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.13827154695636 (code B ref 15648); Fri, 25 Oct 2013 15:38:02 +0000 Original-Received: (at 15648) by debbugs.gnu.org; 25 Oct 2013 15:37:49 +0000 Original-Received: from localhost ([127.0.0.1]:43634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZjSO-0001Sq-SC for submit@debbugs.gnu.org; Fri, 25 Oct 2013 11:37:49 -0400 Original-Received: from mail-qa0-f45.google.com ([209.85.216.45]:51954) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZjSM-0001SW-BJ for 15648@debbugs.gnu.org; Fri, 25 Oct 2013 11:37:46 -0400 Original-Received: by mail-qa0-f45.google.com with SMTP id ii20so648480qab.4 for <15648@debbugs.gnu.org>; Fri, 25 Oct 2013 08:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lifelogs.com; s=google; h=from:to:cc:subject:organization:references:mail-copies-to :gmane-reply-to-list:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=qZxZ1X8IG7k6HVWtcrrDutUmkv0zRE/i5loiW77BxfI=; b=RzB5qTcYe9Gti1viu0XDxvCgGjUzt1VLiobO21dRObXu5P88igLBULOzx2MZ/N+BNv sNJ5dHEKmn9HBkQexeOy5JTyTtIN3SecjnCqNsejxKVoWZ7YKRTL+GahIAdUOrFMDK7s CqVPUXROZfGEqPXHw/sO6eKUYDaaSIMX9zY3s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:organization:references :mail-copies-to:gmane-reply-to-list:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=qZxZ1X8IG7k6HVWtcrrDutUmkv0zRE/i5loiW77BxfI=; b=cr/HKE59EAjeerNttc47tKyAYxJTcAfpv/CninkmAf1QxFgor75Qb7QjWih/dZT5AS FpB6ccyMgtVdNWB4B9i8N8m/xw5qahkVywb1y9tEfaBjof78TrdUqCv3N8XbbkjBHEru B1hrR+YeV9quO+P+3Kw/S3a/9bbhgHygZqQuNxqBzbEFsr94ff/PwxUBXn82NoVVCrvb vpSvYTVd6w5sy7Mbvt1lWmMXLRvSoZwIukLW3gvy3lziRkIon4lGyT4kXqJa63grdcyM gYIL5pn6oCLkiP/BtLTscY+uiRM6F/+FHqBndpC+gexwX0d1dJ1rexhJ7Dvdca2AxzoL qyFg== X-Gm-Message-State: ALoCoQnrq88W9t7efGKx8uxPBTyroFwNRkhuu8OPNthU2AvubcBhe6fRbd7fQB3UXHUpkoaHUwSy X-Received: by 10.49.39.161 with SMTP id q1mr11581005qek.66.1382715460572; Fri, 25 Oct 2013 08:37:40 -0700 (PDT) Original-Received: from flea.lifelogs.com (c-98-229-61-72.hsd1.ma.comcast.net. [98.229.61.72]) by mx.google.com with ESMTPSA id ge5sm14370592qeb.5.2013.10.25.08.37.39 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 25 Oct 2013 08:37:40 -0700 (PDT) X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Gmane-Reply-To-List: yes In-Reply-To: <83iowlh27q.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 25 Oct 2013 17:09:13 +0300") User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) 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:79645 Archived-At: On Fri, 25 Oct 2013 17:09:13 +0300 Eli Zaretskii wrote: EZ> However, to find the best place where to fix this in Emacs, could you EZ> please help me understand in more detail what happens in this case? I EZ> imagine that gnutls-boot is called with the parameters that specify a EZ> certificate file that GnuTLS cannot access. But why isn't this caught EZ> inside gnutls-boot, and how come we allow a NULL gnutls_state be EZ> plugged into the process object? This fragment from gnutls-boot: EZ> GNUTLS_LOG (1, max_log_level, "gnutls_init"); EZ> ret = fn_gnutls_init (&state, GNUTLS_CLIENT); EZ> XPROCESS (proc)->gnutls_state = state; EZ> if (ret < GNUTLS_E_SUCCESS) EZ> return gnutls_make_error (ret); EZ> ought to fail. The bug report cites this error message: EZ> GnuTLS error: #, -64 EZ> Is that error the result of the above error checking? (btw, no idea why the subject keeps getting duplicated but it's annoying) Hard to tell if -64 means anything, but it shouldn't cause a crash. 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. 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? In this specific case I traced the function calls all the way down the GnuTLS library and see that it checks that file was opened correctly and more. It should return an error for that missing file. http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob_plain;f=lib/gnutls_x509.c;hb=HEAD gnutls.git/lib/gnutls_x509.c:gnutls_certificate_set_x509_trust_file() ... cas.data = (void*)read_binary_file (cafile, &size); if (cas.data == NULL) { gnutls_assert (); return GNUTLS_E_FILE_ERROR; } and read_binary_file uses this code: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob_plain;f=gl/read-file.c;hb=HEAD gnutls.git/gl/read-file.c:fread_file(): ... if (fstat (fileno (stream), &st) >= 0 && S_ISREG (st.st_mode)) I can't test this specific issue so it's hard to know where the error is happening. Can anyone duplicate that problem? I could add extra debugging and checking but I don't understand, if the file name is invalid, how the fread_file() function is succeeding. Maybe that's part of the problem. Ted