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>]

emacs@kosowsky.org wrote at about 18:27:23 -0400 on Tuesday, October 22, 2013:
 > emacs@kosowsky.org wrote at about 15:10:29 -0400 on Tuesday, October 22, 2013:
 >  > emacs@kosowsky.org wrote at about 11:41:09 -0400 on Tuesday, October 22, 2013:
 >  >  > emacs@kosowsky.org wrote at about 11:23:59 -0400 on Tuesday, October 22, 2013:
 >  >  >  > Ted Zlatanov wrote at about 09:27:06 -0400 on Tuesday, October 22, 2013:
 >  >  >  >  > On Mon, 21 Oct 2013 15:30:40 -0400 <emacs@kosowsky.org> wrote: 
 >  >  >  >  > 
 >  >  >  >  > > Ted Zlatanov wrote at about 10:22:03 -0400 on Monday, October 21, 2013:
 >  >  >  >  > >> On Fri, 18 Oct 2013 14:29:04 -0400 "" <emacs@kosowsky.org> wrote: 
 >  >  >  >  > >> 
 >  >  >  >  > >> >   Fault Module Name:			libgnutls-28.dll
 >  >  >  >  > >> ...
 >  >  >  >  > >> > That being said, I downloaded 24.3 from the gnu site and tried it with
 >  >  >  >  > >> > the latest gnutls-3.0.9  dll's from the suggested
 >  >  >  >  > >> > http://sourceforge.net/projects/ezwinports/files/ site.
 >  >  >  >  > >> 
 >  >  >  >  > >> > And SAME crash of emacs!
 >  >  >  >  > >> 
 >  >  >  >  > >> Could you please try with the latest 3.x from
 >  >  >  >  > >> ftp://ftp.gnutls.org/gcrypt/gnutls/w32/ ?
 >  >  >  >  > >> 
 >  >  >  >  > > Same crash with 3.2.4 as with 3.0.9
 >  >  >  >  > 
 >  >  >  >  > Sorry, I don't know how you can be sure of the library loaded in
 >  >  >  >  > Windows.  Did you put the DLL in the same directory?
 >  >  >  > 
 >  >  >  > The dll's are in a directory that lies within my system PATH.
 >  >  >  > I know they are loaded because (gnutls-available-p) only proves true
 >  >  >  > when I have all the related dll's in the PATH.
 >  >  >  > 
 >  >  >  >  > 
 >  >  >  >  > >> The `gnutls-boot' function is pretty inoffensive so let's make sure the
 >  >  >  >  > >> basics are covered before we dig into the C code.
 >  >  >  >  > 
 >  >  >  >  > Are you able to debug the Emacs executable?  I don't know if the build
 >  >  >  >  > you're using includes the necessary symbols, but a backtrace with at
 >  >  >  >  > least function names would be extremely helpful to figure this out.
 >  >  >  > 
 >  >  >  > I just used edebug... for the trace I submitted...
 >  >  >  >  > 
 >  >  >  >  > Does the problem occur to any server or just the one you listed?  You
 >  >  >  >  > can test with
 >  >  >  >  > 
 >  >  >  >  >  (open-gnutls-stream "tls" "tls-buffer" "imap.gmail.com" "imaps")
 >  >  >  >  > 
 >  >  >  > 
 >  >  >  > This gave the same crash!
 >  >  >  > 
 >  >  >  >  > It's strange that there's been no other reports of this issue.  Do you
 >  >  >  >  > have access to any other systems where you can test?
 >  >  >  > 
 >  >  >  > Could it have anything to do with 64-bit Win7?
 >  >  >  > Could there be any conflicts with cygwin x86_64 that I have installed
 >  >  >  > (though I purposely didn't install cygwin gnutls) -- but could other
 >  >  >  > dll's be in conflict?
 >  >  > 
 >  >  > OK - I answered my own question.
 >  >  > There seems to be an incompatibility with the cygwin-mount library...
 >  > 
 >  > In particular, the problem seems to be with the called cygwin mount
 >  > program (/bin/mount.exe). Replacing it with /bin/true.exe prevents the
 >  > crash.
 >  > 
 >  > I wonder whether this is a dll incompatibility with cygwin.dll or in
 >  > particular the x86_64 version...
 > 
 > I did some more troubleshooting... actually, I don't think it is a
 > cygwin.dll problem nor is it a problem with the cygwin program
 > mount.exe.
 > 
 > 
 > The problem seems to be with the lisp code in cygwin-mount-activate in
 > terms of how it changes file-name-handler-alist,
 > substitute-in-file-name, and expand-file-name.
 > 
 > I say this because gnutls causes the crash after
 > (cygwin-mount-activate) is run. But if you wait to run
 > (cygwin-mount-deactivate), then it won't crash. So the problem isn't
 > with whether mount.exe has been run (I also double checked this by
 > manually running mount.exe via call-process). Rather, it has something
 > to do with the file name substitutions set up.
 > 
 > So, while the physical crash may be somewhere in the lisp code. The
 > issue is with how the cygwin file name handler lisp code interacts with the
 > gnutls code...

Oops I spoke too soon. Cygwin-mount works just fine and properly
parses the file names in the guntls code.

Rather,  the problem is in how the C-code handles the Cygwin/Linux
style paths enumerated in the Lisp variable:
(defcustom gnutls-trustfiles
  '(
    "/etc/ssl/certs/ca-certificates.crt" ; Debian, Ubuntu, Gentoo and Arch Linux
    "/etc/pki/tls/certs/ca-bundle.crt"   ; Fedora and RHEL
    "/etc/ssl/ca-bundle.pem"             ; Suse
    "/usr/ssl/certs/ca-bundle.crt"       ; Cygwin
    )

If I set the final element to the Windows style path equivalent:
   "C:/cygwin/usr/ssl/certs/ca-bundle.crt"
then gnutls works fine without crashing. So, the problem clearly is
with *nix-style paths

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).

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.

In any case, I imagine the C-code crashes because it sees a Unix-style
path while expecting a Windows style path... 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.