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: Wed, 23 Oct 2013 19:45:48 -0400 Message-ID: <21096.24492.292723.589004@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> <87y55kjayp.fsf_-_@flea.lifelogs.com> <21096.1667.116936.254737@consult.pretender> <83eh7bj1yq.fsf@gnu.org> <87ppqvke5u.fsf@flea.lifelogs.com> 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 1382572033 4724 80.91.229.3 (23 Oct 2013 23:47:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Oct 2013 23:47:13 +0000 (UTC) Cc: emacs@kosowsky.org, 15648@debbugs.gnu.org To: Ted Zlatanov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 24 01:47:16 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 1VZ88y-0005jH-41 for geb-bug-gnu-emacs@m.gmane.org; Thu, 24 Oct 2013 01:47:16 +0200 Original-Received: from localhost ([::1]:51881 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZ88x-0002BC-J4 for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Oct 2013 19:47:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZ88p-0002B3-Mb for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 19:47:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZ88k-00074J-An for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 19:47:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53474) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZ88k-00074E-7K for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 19:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VZ88j-0007Q0-NP for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 19:47:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Oct 2013 23:47: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.138257199228478 (code B ref 15648); Wed, 23 Oct 2013 23:47:01 +0000 Original-Received: (at 15648) by debbugs.gnu.org; 23 Oct 2013 23:46:32 +0000 Original-Received: from localhost ([127.0.0.1]:39260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZ88F-0007PG-IY for submit@debbugs.gnu.org; Wed, 23 Oct 2013 19:46:32 -0400 Original-Received: from vms173013pub.verizon.net ([206.46.173.13]:59889) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZ88C-0007Ow-Sv for 15648@debbugs.gnu.org; Wed, 23 Oct 2013 19:46:29 -0400 Original-Received: from consult.pretender ([unknown] [72.93.211.25]) by vms173013.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MV500J3LBCDUJK0@vms173013.mailsrvcs.net> for 15648@debbugs.gnu.org; Wed, 23 Oct 2013 18:46:05 -0500 (CDT) Original-Received: from consult.pretender (consult.pretender [127.0.0.1]) by consult.pretender (8.14.4/8.14.4) with ESMTP id r9NNjmhY031273; Wed, 23 Oct 2013 19:45:48 -0400 In-reply-to: <87ppqvke5u.fsf@flea.lifelogs.com> 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:79559 Archived-At: 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 wrote: > > >> From: > >> 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...