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

[<emacs@kosowsky.org>]

Eli Zaretskii wrote at about 18:16:33 +0300 on Wednesday, October 23, 2013:
 > > From: <emacs@kosowsky.org>
 > > Date: Wed, 23 Oct 2013 00:17:49 -0400
 > > Cc: Ted Zlatanov <tzz@lifelogs.com>, 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...