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]

Eli Zaretskii wrote at about 21:00:21 +0300 on Wednesday, October 23, 2013:
 > > From: <emacs@kosowsky.org>
 > > Date: Wed, 23 Oct 2013 13:12:56 -0400
 > > Cc: emacs@kosowsky.org, tzz@lifelogs.com, 15648@debbugs.gnu.org
 > > 
 > > 4. This small patch to gnutls.el will fix the problem by expanding the
 > > file name to a full, valid path:
 > 
 > Sorry, but I cannot accept this.  There's absolutely no reason to run
 > the file through expand-file-name at that place.

There is a *great* reason to add expand-file-name *any* time you pass
a file name or path to external C-code that references the file
system.

This is necessary (and should be best or even required practice) since
Emacs by design may include various filehandlers (like cygwin-mount)
that internally translate path names before accessing the file system
while external C-code has no way of knowing that the path names need
transformation. This is particularly important since the Emacs
filehandlers may be turned on and off or changed at will or
dynamically and the C-code can't possibly know that, so it can't
possibly know how and when to perform the required file handling
operations to access the file system.

Thus, I would argue that it is best practice to use expand-file-name
whenever a file path is passed from Emacs lisp to C-code to ensure
that a system valid (absolute) path is ultimately passed to the file
system independent of how Emacs may be translating paths internally.

 > More importantly, there's no reason to believe this is the only
 > place where the same problem could surface.

There is a wonderful reason to so believe since It is the only place
that gnutls-trustfiles is referenced... hence, it is the natural place to
fix it.

It's pretty simple. You really have only 3 choices:

1. Only allow path names in gnutls-trustfiles that are native and
   understandable as-is to the machine.  In particular, this would
   mean deleting the default gnutls-turstfiles cgywin entry since it
   is written relative to cygwin root which is not known to the C-code
   or to the system. Note that making the path hard-wired absolute
   wouldn't work for cygwin since while cygwin root is typically
   C:\cygwin, it need not be.. Of course, deleting the cygwin entry is
   reasonable, if you don't care about supporting cygwin by default

2. Add my patch or a similar to ensure that a valid path is always
   passed to the C-code -- whether one is using cygwin mount or any
   other code that changes how Emacs translates path names.  This
   approach is simple and non-harmful, should always work, and in
   general protects the C-code from being passed a non-valid path.

3. Modify the C-code to include cygwin-mount type functionality so
   that the cygwin root is prepended to cygwin style path names. This
   is probably not an easy or practical solution since it requires
   changing the compiled C-library with calls to various cygwin
   functions and libraries. Also, it would only work for the file
   handler modifications of cygwin-mount and not to other possible
   file handlers -- thus modifying the C-code would be brittle,
   non-general, and non-portable.

Leaving it as-is shouldn't be an acceptable solution since without
cygwin-mount, the cygwin entry is meaningless and is *never* used --
so it's wasteful at best and confusing or crash-inducing at
worst. Even worse, with cygwin-mount, it causes a crash of the entire
Emacs process.

So, this is a BUG in the Emacs code -- it needs to be fixed!
If you don't like my fix, then feel free to find another...

Of course, there is still arguably a bug in the C-code since passing
an invalid path to the gnutls-boot C-code should not cause the entire
Emacs process to crash.

This bug should be easily reproducible by passing a cygwin path to
gnutls-boot under Windows

 > >  > 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.
 > 
 > Only by sheer luck.

Really? I can pretty much guarantee it will always fix the problem for
gnutls.el since there is no other reference to gnutls-trustfiles. The
alternative fix is to delete the cygwin entry.