From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.bugs Subject: bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to crash completely Date: Mon, 11 Nov 2013 16:53:31 -0500 Message-ID: <21121.20955.967319.163790@consult.pretender> References: <21089.32240.198931.971000@consult.pretender> <87fvrun1pw.fsf@flea.lifelogs.com> <21093.32992.278229.646703@consult.pretender> <877gd5mo5x.fsf@flea.lifelogs.com> <21094.39055.449629.706850@consult.pretender> <21094.40085.664080.69561@consult.pretender> <21094.52645.645440.977584@consult.pretender> <21094.64459.131668.849138@consult.pretender> <21095.19949.639350.970770@consult.pretender> <21096.24492.292723.589004@consult.pretender> <87eh7bj5no.fsf_-_@flea.lifelogs.com> <21097.10816.221279.461499@consult.pretender> <21097.27136.910137.181740@consult.pretender> <21098.31018.184128.497305@consult.pretender> <87y555socz.fsf@flea.lifelogs.com> <21110.26587.721061.28128@consult.pretender> <83fvrd9ysr.fsf@gnu.org> <877gcorv0r.fsf@flea.lifelogs.com> <83sivc85pe.fsf@gnu.org> <21121.11298.564313.363452@consult.pretender> <83bo1q3dqh.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1384206915 16618 80.91.229.3 (11 Nov 2013 21:55:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Nov 2013 21:55:15 +0000 (UTC) Cc: tzz@lifelogs.com, emacs@kosowsky.org, 15648@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 11 22:55:18 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VfzS0-0003L1-Cx for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Nov 2013 22:55:16 +0100 Original-Received: from localhost ([::1]:39787 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VfzRz-00058S-OW for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Nov 2013 16:55:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33460) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VfzRs-00056t-28 for bug-gnu-emacs@gnu.org; Mon, 11 Nov 2013 16:55:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VfzRn-0000FS-5C for bug-gnu-emacs@gnu.org; Mon, 11 Nov 2013 16:55:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33491) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VfzRn-0000DU-0e for bug-gnu-emacs@gnu.org; Mon, 11 Nov 2013 16:55:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VfzRm-0003BL-6T for bug-gnu-emacs@gnu.org; Mon, 11 Nov 2013 16:55:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Nov 2013 21:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15648 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15648-submit@debbugs.gnu.org id=B15648.138420687412194 (code B ref 15648); Mon, 11 Nov 2013 21:55:02 +0000 Original-Received: (at 15648) by debbugs.gnu.org; 11 Nov 2013 21:54:34 +0000 Original-Received: from localhost ([127.0.0.1]:47510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VfzRF-0003AX-31 for submit@debbugs.gnu.org; Mon, 11 Nov 2013 16:54:30 -0500 Original-Received: from vms173005pub.verizon.net ([206.46.173.5]:47454) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VfzRC-0003AG-5y for 15648@debbugs.gnu.org; Mon, 11 Nov 2013 16:54:27 -0500 Original-Received: from consult.pretender ([unknown] [72.93.211.153]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MW400MGBCT8IYC1@vms173005.mailsrvcs.net> for 15648@debbugs.gnu.org; Mon, 11 Nov 2013 15:53:49 -0600 (CST) Original-Received: from consult.pretender (consult.pretender [127.0.0.1]) by consult.pretender (8.14.4/8.14.4) with ESMTP id rABLrVRD023375; Mon, 11 Nov 2013 16:53:32 -0500 In-reply-to: <83bo1q3dqh.fsf@gnu.org> X-Mailer: VM 8.2.0b under 23.1.1 (i386-redhat-linux-gnu) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:80286 Archived-At: Eli Zaretskii wrote at about 22:06:14 +0200 on Monday, November 11, 2013: > > From: > > Date: Mon, 11 Nov 2013 14:12:34 -0500 > > Cc: Ted Zlatanov , 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...