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

[emacs]

emacs@kosowsky.org wrote at about 19:45:48 -0400 on Wednesday, October 23, 2013:
 > Ted Zlatanov wrote at about 14:58:21 -0400 on Wednesday, October 23, 2013:
 >  > On Wed, 23 Oct 2013 21:07:09 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 
 >  > 
 >  > >> From: <emacs@kosowsky.org>
 >  > >> Date: Wed, 23 Oct 2013 13:25:23 -0400
 >  > >> Cc: emacs@kosowsky.org, 15648@debbugs.gnu.org
 >  > >> 
 >  > >> Ted Zlatanov wrote at about 10:52:46 -0400 on Wednesday, October 23, 
 > 2013:
 >  > >> > Please put this on hold while we discuss it in the GnuTLS mailing 
 > list
 >  > >> > and let's update it when (if) we find a solution there.  It seems to 
 > be
 >  > >> > outside the Emacs code right now.
 >  > >> > 
 >  > >> As per my previous email, the following trivial patch will fix the
 >  > >> Emacs code to make sure that valid paths are always passed...
 >  > 
 >  > EZ> Thanks, but I'm firmly against such work-arounds.  A file name does
 >  > EZ> not need to be fully resolved to be valid.
 > 
 > Well, given that Emacs *officially* supports the use of file handlers
 > (see Elips info 25.11 Making Certain File Names "Magic"), one should
 > be able to expect that properly written file handlers -- i.e. ones
 > that address all the documented file access primitives -- should work
 > with all officially sanctioned Emacs library code.
 > 
 > Indeed the Elisp documentation states:
 >         "Here are the operations that a magic file name handler gets to
 >         handle:
 >         `access-file', `add-name-to-file', `byte-compiler-base-file-name',
 >         `copy-directory', `copy-file', `delete-directory', `delete-file',
 >         `diff-latest-backup-file', `directory-file-name', `directory-files',
 >         `directory-files-and-attributes', `dired-compress-file',
 >         `dired-uncache',
 >         `expand-file-name', `file-accessible-directory-p', `file-attributes',
 >         `file-directory-p', `file-executable-p', `file-exists-p',
 >         `file-local-copy', `file-remote-p', `file-modes',
 >         `file-name-all-completions', `file-name-as-directory',
 >         `file-name-completion', `file-name-directory',
 >         `file-name-nondirectory',
 >         `file-name-sans-versions', `file-newer-than-file-p',
 >         `file-ownership-preserved-p', `file-readable-p', `file-regular-p',
 >         `file-in-directory-p', `file-symlink-p', `file-truename',
 >         `file-writable-p', `file-equal-p', `find-backup-file-name',
 >         `get-file-buffer', `insert-directory', `insert-file-contents',
 >         `load', `make-auto-save-file-name', `make-directory',
 >         `make-directory-internal', `make-symbolic-link',
 >         `process-file', `rename-file', `set-file-modes', `set-file-times',
 >         `set-visited-file-modtime', `shell-command', `start-file-process',
 >         `substitute-in-file-name',
 >         `unhandled-file-name-directory', `vc-registered',
 >         `verify-visited-file-modtime',
 >         `write-region'.
 > 
 >         ... The handler function must handle all of the above operations, and
 >         possibly others to be added in the future."
 > 
 > Clearly, the intent is that by defining the file handler to address
 > all the above primitive functions, one can be assured that all paths
 > using the handler will be translated properly.
 > 
 > One should not have to worry that some random Emacs library may choose
 > to bypass the primitives by passing non-expanded, potentially
 > non-system recognizable path names to some undocumented C-code that
 > directly accesses the file system.
 > 
 > Since "expand-file-name" is one of the above documented primitives it
 > makes sense that the gnutls.el code pass such a primitive to pass
 > trust file names to the nutls-boot C-code, thus making the handling of
 > such file names robust and portable.
 > 
 > Otherwise, why support file handlers at all and why be so careful to
 > document the notion of primitive if there are official Emacs libraries
 > that knowingly bypass such primitives, causing the file handler to
 > inexplicably fail without any documentation or rational reason.
 > 
 > This is not just about cygwin-mount. Since file handlers are an
 > officially supported feature of Emacs, I should be able to for example
 > write a handler that recognizes '~~' as a synonym for /mnt/media and
 > expect that "~~/myvideos" will always resolve to "/mnt/media/myvideos"
 > in any officially sanctioned Emacs function or library.
 > 
 > I should not have to read through the code of every official Emacs
 > library to determine whether or not they bypass the standard file
 > access primitives by calling some obscure, undocumented C-code. Isn't
 > this the entire purpose of having well-defined and documented
 > primitives in the first place?
 > 
 > If the maintainers of Emacs disagree, then the file handler feature
 > needs to be deprecated and eliminated... since a feature that cannot
 > be relied on to work properly within Emacs' own code base is worse
 > than not having it at all.
 > 
 > The irony is that the patch to fix this is about as simple and natural
 > as can be... simply use one reference to the primitive
 > "expand-file-name". Conversely, without such a patch there is no other
 > way of making file handlers work with gnutls!
 > 
 > 
 >  > Right, and in addition any file name at all handed to a C library should
 >  > not crash Emacs :)
 > 
 > True! but even if the C-code is fixed so as not to crash
 > Emacs, there is still a bug in the gnutls.el code in that it includes
 > a Cygwin path as part of the definition of gnutls-trustfiles that
 > can't possibly EVER EVER work -- whether you are using cygwin-mount or
 > not -- even if the C-code is patched so as not to crash.
 > 
 > Either the bug is in including a Cygwin path or in not using a simple
 > path expansion to make the Cygwin path work. You can't include a
 > Cygwin path but write code in the very same library that by design
 > won't support it's own feature!
 > 
 > Of course, the more general principle is that all official Emacs code
 > should play nicely with core Elisp functionality...

Just one addendum...

If the maintainers of gnutls.el for some presumably unstated by
compelling reason do not want to support Magic File names (aka file
handlers), then the library code should:

1. Properly disable the use of file handlers so that modified
   primitives (like file-exist-p) fail on cygwin paths.

   One way would be to add the following line to the let* statement in
   gnutls-negotiate:
                (file-name-handler-alist nil)

2. DOCUMENT that gnutls doesn't support Magic File names