bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to crash completely

[emacs]

Ted Zlatanov wrote at about 06:59:39 -0400 on Thursday, October 24, 2013:
 > On Wed, 23 Oct 2013 19:45:48 -0400 <emacs@kosowsky.org> wrote: 
 > Provide a backtrace, please.  I promise you we'll consider your proposal
 > and all the alternatives as soon as we know what's broken.

OK... but before I invest in downloading and running a C-debugger,
I want to be clear that there are actually 2 bugs here - one at the
elisp level and one at the C-level

1. At the elisp level, gnutls.el fails to consistently and
   appropriately handle (or disable) Magic Files aka file handlers
   (including in particular, cygwin-mount).

   Specifically, gnutls-negotiate uses the Magic File associated
   primitive file-exists-p to test for the existence of a file but
   then passes off the unmodified (and non-existent) Magic File path
   (e.g., path relative to cygwin root) to some C-code. Clearly, short
   of passing nearly the entire Emacs state (including variable &
   function defs) to the C-code, it is impossible for the C-code to
   know what file handler to use to translate the Magic File into a
   system recognizable and valid path.

   I believe the nature of this bug is fully explored and understood.
   
   The solution is to treat Magic files appropriately and consistently
   either (1) by using the Magic File aware primitive expand-file-name
   to expand the file name before passing off to the C-code or (2)
   disabling Magic file handlers (and documenting that fact)

2. At the C-code level, there is a bug in that passing a
   non-existent/invalid file path may cause the entire Emacs code to
   crash.

   It is this bug that requires further C-source debugging to identify
   the source...

 > I will gladly make the change to avoid a path like
 > "/usr/ssl/whatever" that doesn't work in Cygwin, but I don't want
 > to make that change in order to hide an underlying problem.

Again, the issue is broader than just Cygwin paths... the code as-is
fails to handle any type of Magic File and associated file
handlers... and there is no reason or way for a user to suspect or
know that the officially include Emacs library gnutls.el chooses not
to handle Magic files correctly -- short of debugging, tracing, and
reading the detailed gnutls.el elisp code.


Also, as above, there is both a problem in the gnutls.el code AND in
the underlying C-code

 > In other words, if a magic path can break Emacs because of some library
 > interaction beneath the ELisp code, the fix is *probably* not at the
 > ELisp level because there are so many potential trigger points for the
 > bad behavior.

Wrong - the opposite is true. Handling of magic files via their
associated file handlers can *only* be done generally and properly at
the elisp level since short of passing the entire Emacs state to
external C-code, there is no way of the C-code knowing how to handle
potentially arbitrary file handlers.

It's very simple. File access and reference should only be done
via Magic File aware primitives. In particular, when passing a path to
external C-code, that code should first be translated by something like
expand-file-name to system-recognizable and valid paths.