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

[emacs]

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