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

[<emacs@kosowsky.org>]

Eli Zaretskii wrote at about 22:06:14 +0200 on Monday, November 11, 2013:
 > > From: <emacs@kosowsky.org>
 > > Date: Mon, 11 Nov 2013 14:12:34 -0500
 > > Cc: Ted Zlatanov <tzz@lifelogs.com>, emacs@kosowsky.org, 15648@debbugs.gnu.org
 > > 
 > > Well, there is also the problem that "/usr" is never present as a root
 > > path on any (standard) Windows machine, so that the path commented as
 > > being valid for cygwin actually never works! 
 > 
 > Please don't assume that what happens on your machine happens on
 > everyone else's.  E.g., my systems do have a /usr directory at least
 > on some of the drives.  No, I don't run Cygwin.

OK... for the pedantic, I will explain what I mean by "standard
Windows machine"... on probably about 99.999% of Windows machines,
there is no /usr lying at the root of the C-drive. I am probably being
generous given that (1) so few Windows machines have a Unix-like tree
anywhere (2) Of those that do and also have Emacs, most are probably
are using cygwin which doesn't put the root at /

 > More generally, "/foo/bar" is a valid file name on Windows, whether
 > foo equals "usr" or not.  It is simply wrong to assume that if you see
 > /usr on Windows, it _must_ mean a Cygwin mount.  This kind of
 > reasoning is simply a non-starter.

I *never* ever claimed that. Why would I claim that? Creating a
(false) straw man and calling it a "non-starter" is not very
productive.

I merely claim that if one is using a *valid* magic file handler like
cygwin-mount, then gnutls should not crash by virtue of having a magic
file handler installed.

 > > The absence of cygwin-mount magic file handling when a file name is
 > > passed directly to the gnutls c-code without going through any of the
 > > standard magic-file-handling file access routines is the crux of the
 > > problem.

 > No, the crux of the problem is that you are trying to use a natively
 > built Emacs with file names that make sense only for Cygwin programs.

No, the crux of the problem was and is a bug in the gnutls.el code,
due to the inconsistency in which magic files are handled.
1. file-exists-p is enabled with magic file handling turned on
2. The pass to c-code ignores magic file handling
3. This causes gnutls.el to crash with a totally incomprehensible
   error message and an equally incomprehensible return code of '-64'

Gnutls needs to treat magic files consistently... even if it simply
chooses to ignore magic file handling (in a consistent way), then
such behavior should ideally be documented in the code.

 > If you want Cygwin semantics of file names, use a Cygwin build of
 > Emacs, and this problem will immediately go away.  Alternatively, use
 > file names for your certificates that native Windows programs can
 > find, and the problem will also go away immediately.

That is your opinion. Your suggestions that I limit myself to using a
cygwin-compiled version of emacs are just a workaround for poor
coding. I'm sorry.

Others have written cygwin-mount specifically for the use case that I
have. Since when are the two choices you list, the only ones allowed?
This whole idea of doing it just your way (or any way) goes against
the entire emacs philosophy.

Cygwin-mount is a perfectly valid elisp library that does everything a
magic file handler is supposed to do. Rather, the problem lies solely
with the gnutls code. If the authors choose to shut off magic file
handling in gnutls consistently, then I would be disappointed in the
limitations and unnecessary inflexibility of the gnutls code, though I
couldn't argue that it was buggy.

Magic file handling is a core emacs feature. You have to take such
functionality into account whether you choose to leverage it or
not... or else you are contributing to making emacs buggy and
inconsistent (along with limiting its power)

 > 
 > > So, again I see only 2 solutions:
 > > 1. Change (or omit) the "/usr" path and make it relative to cygwin
 > >    root (though this would not work generally since cygwin root is
 > >    changeable)
 > > 
 > > 2. Implement magic handling so that paths are automagically translated
 > >    to be correct at the file system level. In this case, by inserting
 > >    the cygwin root.
 > 
 >   3. Don't mix Cygwin file names with native Windows programs.

#3? Where did you come up with that restriction? Is it documented
somewhere in the Emacs/Elisp manuals and/or in the release notes? Or
did you invent that restriction out of thin air?

I think you are missing the point that gnutls.el has an inherent
inconsistency independent of cygwin or anything else...

Specifically, it leaves magic file handling on when using file-exists-p
to check whether the file exists but then ignores magic file handling
when passing the file to the OS.

The net result is that any path in gnutls-trustfiles that is valid to
a magic file handler but invalid to the OS will cause gnutls to crash
every time without any user-readable explanation. Even worse,
gnutls.el contains a default path labeled "cygwin" that will only work 
with a specially compiled cygwin version of emacs.

This is sloppy coding... no excuse for it... nothing to do with cygwin
or cygwin-mount except that cygwin mount happened to surface the
problem. Even worse, your obstinate refusal to fix the issue is simply
unbelievable.

I have proposed a valid, workable, and very tiny patch. Moreover, my
patch is totally consistent with the usage of expand-file-name in
particular and magic file handlers in particular as used dozens of
times in file.el

You have failed to give a single use case where my patch would cause
any problems. My patch adds immeasurably trivial complexity and
processing time to the routine. In contrast, all you have done is
suggest one-off workarounds which do nothing to solve the problem for
the next unsuspecting user...