From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to crash completely Date: Tue, 12 Nov 2013 19:42:23 +0200 Message-ID: <83ppq51pq8.fsf@gnu.org> 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> <21121.20955.967319.163790@consult.pretender> <834n7i2rzd.fsf@gnu.org> <21122.18190.51311.720353@consult.pretender> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1384278193 25836 80.91.229.3 (12 Nov 2013 17:43:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Nov 2013 17:43:13 +0000 (UTC) Cc: tzz@lifelogs.com, 15648@debbugs.gnu.org To: emacs@kosowsky.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 12 18:43:17 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 1VgHzg-0005Ry-PH for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Nov 2013 18:43:16 +0100 Original-Received: from localhost ([::1]:44412 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgHzg-0007BY-E3 for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Nov 2013 12:43:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51285) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgHzY-0007BP-5P for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2013 12:43:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VgHzS-0005Bm-NA for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2013 12:43:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35048) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgHzS-0005Bc-JM for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2013 12:43:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VgHzR-0008K6-Su for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2013 12:43:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Nov 2013 17:43:01 +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.138427816031965 (code B ref 15648); Tue, 12 Nov 2013 17:43:01 +0000 Original-Received: (at 15648) by debbugs.gnu.org; 12 Nov 2013 17:42:40 +0000 Original-Received: from localhost ([127.0.0.1]:49067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VgHz4-0008JT-VO for submit@debbugs.gnu.org; Tue, 12 Nov 2013 12:42:39 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:48663) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VgHz0-0008J3-8I for 15648@debbugs.gnu.org; Tue, 12 Nov 2013 12:42:36 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MW500E00VO0Y400@a-mtaout23.012.net.il> for 15648@debbugs.gnu.org; Tue, 12 Nov 2013 19:42:26 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MW500EX7VUPUQ70@a-mtaout23.012.net.il>; Tue, 12 Nov 2013 19:42:26 +0200 (IST) In-reply-to: <21122.18190.51311.720353@consult.pretender> X-012-Sender: halo1@inter.net.il 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:80334 Archived-At: > From: > Date: Tue, 12 Nov 2013 10:19:42 -0500 > Cc: emacs@kosowsky.org, tzz@lifelogs.com, 15648@debbugs.gnu.org, > Stefan Monnier > > Stefan -- please pay attention to the hostile, unfriendly attitude and > ultimate arrogance of the Windows Emacs maintainer... There's no hostility here. Disagreement, yes; but that's something different. As for the other vices, I'll leave it to others to judge that. > > > 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 > > > > Only because you use cygwin-mount. > > Or any other magic file handler... > where file-exists-p changes the file path from something not OS > recognizable to something OS recognizable. No, cygwin-mount is fundamentally different from most (all?) other file-handlers. IMO, it is also a far cry from what the current design of file-handlers in Emacs assumes. Let me explain. First, "magic file names" are IMO really a euphemism. A much more accurate term is "remote" or "foreign" file names. At least this is the only interpretation I can think of under which the current design of file-handlers makes sense. Specifically, Emacs does not want to know anything about handling such files -- it just calls the handler and returns the result, without any additional processing. Emacs does that consistently in many primitives, and therefore it assumes that a handler for a class of file names will implement _all_ of the handlers for those operations that make sense with that class of files. By contrast, cygwin-mount implements handlers for a very small set (I think 3 or 4) of file-related operations, and for the rest it turns around and calls Emacs's original code to do the job. But Emacs's internal processing of files assumes without checking that _any_ file not handled by some handler is a local file that fully abides by the conventions of the local filesystem. In particular, the Windows-specific code in Emacs is _riddled_ with such assumptions. It will prepend a drive letter to file names that lack one, convert forward slashes to backslashes and back at will, downcase file names without thinking twice, even convert them to 8+3 alias form in some cases. Put a "magic" or "semi-magic" file name through that code, and you cannot trust the result. Here's a simple example: half way through expand-file-name, Emacs accesses the home directory of a user, to support "~" in file names. This is done entirely in C, so if the home directory is in Cygwin /foo/bar format, the result will be a failure to resolve "~". Another example is with file-attributes: if someone expects to see Cygwin-style emulation of Posix mode bits that resembles what Cygwin's 'ls -l' will show, they will be deeply disappointed at best. Etc., etc. -- there are a lot of use cases where cygwin-mount in its present shape simply isn't complete enough to pretend to be a full-fledged file-handler agent that plays by the rules that Emacs expects. We can add a little Lisp here and a little more there to fix some use case or another, but that just obscures and obfuscates the code, and in a few months or years no one knows why we have this or that piece of code with some strange effect. Now, it might be possible to develop cygwin-mount to the degree that it does work reliably (which will most probably mean either introduction of much more hooks into Emacs to allow that, or reimplementation of many of the C portions in Lisp). If someone submits patches to do that, it would probably be a welcome addition to Emacs. But we are not there yet. > The same error would occur with ange-ftp and tramp > should you use that style filename in gnutls-trustfiles. gnutls.el doesn't make sense with remote file names, I agree. Your suggestion to bind the handlers alist to nil is IMO TRT for gnutls (as well as for many other Emacs packages). > > > 3. This causes gnutls.el to crash with a totally incomprehensible > > > error message and an equally incomprehensible return code of '-64' > > > > It no longer crashes. > > It doesn't crash emacs... but the routine exist on error without > human-readable explanation (other than an obscure -64 return value). > Is this code? Is this user friendly? Probably not; patches to make that error message more legible are welcome. But please don't underestimate the value of the solution that eliminated the crash: not only Emacs will not crash anymore in that case, something that Emacs should never do due to bugs on the Lisp level, but it also corrected a fundamental flaw in the code, whereby a Lisp object was marked as being a GuTLS connection too early, before it was completely initialized. So I think this bug report served Emacs very well indeed, and thank you for helping us resolve it. > > It's not an issue with code quality. It's simply a consequence of the > > fact that Cygwin file names _cannot_ be consistently supported in > > native Windows programs. You can solve perhaps 95% or 99% of that, > > but not 100%. If you are willing to live with those limitations, > > please be free. But it will never be supported all the way, it simply > > cannot be. > > The perfect is the enemy of the good enough. This goes both ways, you know. > I have offered a patch that substantially improves compatibility > without any downside other than your own unsubstantiated biases. The downside you don't see is the additional code it adds to Emacs that has no other reason but to support cygwin-mount. There's already more than enough code in Emacs which no one fully understands, because it was introduced to "fix" this or that corner case on Windows. With almost all the active maintainers coming from the Posix world, I fear that leaving all this stuff, let alone adding to it, is a slippery slope to an abyss. > > You are entitled to your opinions. But I respectfully disagree, and > > as long as I'm hold responsible for the Windows port of Emacs, I'm > > sorry, but my opinions weigh slightly more. > > You are being arrogant. Emacs is about more people than just yourself > and about more use cases than just you. Such an attitude is > incongruous with an open source project and discourages both users and > participants. > > If such an attitude persists, I will regret helping with debugging > this and taking my precious time to test your c-code fix. I had > already fixed the problem myself, so with your attitude why would I > share my insights with you. I'm sorry that you feel that way. I tried to explain above why your help was very important and appreciated beyond the narrow context of the crash. > > Except that Cygwin "magic" cannot be reliably handled that way. The > > difference is that for other magic file names, we have a handling > > agent that is outside of Emacs. By contrast, cygwin-mount pretends to > > do that entirely in Emacs Lisp, which cannot work reliably enough. As > > this example shows. > > It will happen with almost any file handler that uses file-exists-p. I agree that gnutls.el should ignore the file handlers when it tests for existence of certificate files. Clearly, having those files on remote systems makes no sense. That is not where I was disagreeing with you. If that is what I somehow made you understand, I'm sorry for my imperfect wording. > > > > 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? > > > > It's not an invention. It's the result of many years using Emacs on > > Windows and hacking it. You are free to ignore that experience, of > > course, but I assure you it is valid. > > But why would you preclude this from working. > Please give me ONE use case where my patch either causes a failure > elsewhere or where it bogs down the code. I'm not sure we are talking about the same thing. Again, I don't disagree with the change in gnutls.el, to ignore file handlers. What I was talking about was adding code that is only needed to support cygwin-mount, like calling expand-file-name, or changing convert-standard-filename for the same reason. > > As long as the solution is plugging cygwin-mount into more places in > > Emacs, such a solution will not be acceptable, sorry. > > You are biased against cygwin-mount. Yes, I am. I tried to explain above why. I hope now you understand my reasons better.