From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.bugs Subject: bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to crash completely, bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to crash completely Date: Wed, 23 Oct 2013 13:12:56 -0400 Message-ID: <21096.920.835718.562924@consult.pretender> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1382548456 29109 80.91.229.3 (23 Oct 2013 17:14:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Oct 2013 17:14:16 +0000 (UTC) Cc: tzz@lifelogs.com, 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 Wed Oct 23 19:14:19 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 1VZ20f-0007AD-0i for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Oct 2013 19:14:17 +0200 Original-Received: from localhost ([::1]:50684 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZ20e-0006VO-Gb for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Oct 2013 13:14:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZ20V-0006P1-Tb for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 13:14:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZ20R-0005Bh-1b for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 13:14:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52454) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZ20Q-0005Bb-Tl for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 13:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VZ20Q-0003k0-71 for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 13:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Oct 2013 17:14: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: moreinfo Original-Received: via spool by 15648-submit@debbugs.gnu.org id=B15648.138254841614330 (code B ref 15648); Wed, 23 Oct 2013 17:14:02 +0000 Original-Received: (at 15648) by debbugs.gnu.org; 23 Oct 2013 17:13:36 +0000 Original-Received: from localhost ([127.0.0.1]:38238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZ1zz-0003j3-GC for submit@debbugs.gnu.org; Wed, 23 Oct 2013 13:13:35 -0400 Original-Received: from vms173007pub.verizon.net ([206.46.173.7]:52207) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZ1zx-0003iq-U8 for 15648@debbugs.gnu.org; Wed, 23 Oct 2013 13:13:34 -0400 Original-Received: from consult.pretender ([unknown] [72.93.211.25]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MV400GVKT5MPHQ0@vms173007.mailsrvcs.net> for 15648@debbugs.gnu.org; Wed, 23 Oct 2013 12:13:13 -0500 (CDT) Original-Received: from consult.pretender (consult.pretender [127.0.0.1]) by consult.pretender (8.14.4/8.14.4) with ESMTP id r9NHCu4D026043; Wed, 23 Oct 2013 13:12:57 -0400 In-reply-to: <83wql4hvam.fsf@gnu.org> X-Mailer: VM 8.2.0b under 23.1.1 (i386-redhat-linux-gnu) 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:79543 Archived-At: Eli Zaretskii wrote at about 18:16:33 +0300 on Wednesday, October 23, 2013: > > From: > > Date: Wed, 23 Oct 2013 00:17:49 -0400 > > Cc: Ted Zlatanov , 15648@debbugs.gnu.org > > > > Stepping through the *Lisp* code shows that the file paths are all > > properly parsed when cygwin-mount is loaded/activated. Indeed, > > file-exists-p properly recognizes the cygwin path > > "/usr/ssl/certs/ca-bundle.crt" and returns nil on the other paths that > > don't exist in a standard Cygwin setup. > > > > Note that if cygwin-mount is not loaded/activated, then > > "/usr/ssl/certs/ca-bundle.crt" (along with the other list elements) > > fails the file-exists-p test in gnutls-negotiate so that 'trustfiles' > > gets set to nil which explains why it doesn't crash in the case when > > cygwin-mount is not used since trivially 'trustfiles' has no paths > > associated with it. > > > > So, basically, we have the following Catch-22. If cygwin-mount is not > > loaded/activated, then the cert location for Cygwin is never found. If > > cygwin-mount is activated then it causes a crash. The result being > > that in Windows, no certs are ever loaded when using the default > > definition of gnutls-trustfiles > > > > Presumably the problem is that the C-code doesn't know how to deal with > > a Cygwin (*nix) style path that has been properly recognized by the > > Lisp code (via cygwin-mount). > > The native Windows build of Emacs certainly doesn't understand the > magic of Cygwin mounts. How can it? The cygwin-mount package cannot > possibly work for external DLLs that were developed for native Windows > builds of programs which know nothing about Lisp and Emacs file I/O. > > The problem is almost certainly that the GnuTLS code was assured that > a file exists (because Emacs used cygwin-mount), but then the file > could not be reached. I can understand why GnuTLS becomes confused. > > But since you didn't provide any C-level backtraces, we cannot know > where that code is, and thus cannot fix it. > > > It seems like there are two potential solutions: > > 1. Use Windows-style paths in the definition of gnutls-trustfiles > > (this should work in Linux too, since > > "C:/usr/ssl/certs/ca-bundle.crt" will generally fail the > > file-exists-p test) > > > > 2. Add cygwin-mount functionality to the C-code so that it can parse > > cygwin (Unix) style paths. > > 3. Do not use cygwin-mount in conjunction with the native Windows > build of Emacs. > 4. This small patch to gnutls.el will fix the problem by expanding the file name to a full, valid path: --- gnutls.el 2013-03-17 13:52:40.000000000 -0400 +++ gnutls.el.new 2013-10-23 12:47:36.503554500 -0400 @@ -174,7 +174,8 @@ (let* ((type (or type 'gnutls-x509pki)) (trustfiles (or trustfiles (delq nil - (mapcar (lambda (f) (and f (file-exists-p f) f)) + (mapcar (lambda (f) (and f (file-exists-p f) + (expand-file-name f))) (if (functionp gnutls-trustfiles) (funcall gnutls-trustfiles) gnutls-trustfiles))))) > > In any case, I imagine the C-code crashes because it sees a Unix-style > > path while expecting a Windows style path... > > Windows supports Unix-style file names. The problem is that the file > "/usr/ssl/certs/ca-bundle.crt" cannot be found by starting from the > root directory of the current drive. The above proposed patch would fix that problem. > > > that being said the C-code should be better behaved than that... at > > a minimum the code should check to make sure the certificate file > > path is well-formed and exists. > > See above: unless you present the backtrace from the crash, no one can > know where the offending code is, or what it does wrong. Please > provide that data. What do I need to do to get a backtrace? I don't have any C-debugging software on my Windows laptop... and have never done C-code debugging in a Windows environment...