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 20:13:52 -0400 Message-ID: <21096.26176.336797.210676@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> <21096.24492.292723.589004@consult.pretender> 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 1382573716 20543 80.91.229.3 (24 Oct 2013 00:15:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Oct 2013 00:15:16 +0000 (UTC) Cc: Ted Zlatanov , 15648@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 24 02:15: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 1VZ8a5-00065M-Vp for geb-bug-gnu-emacs@m.gmane.org; Thu, 24 Oct 2013 02:15:18 +0200 Original-Received: from localhost ([::1]:51939 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZ8a5-0005yU-4x for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Oct 2013 20:15:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43023) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZ8Zw-0005y5-Vv for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 20:15:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZ8Zr-0005qh-K7 for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 20:15:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53530) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZ8Zr-0005q7-HO for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 20:15:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VZ8Zq-00087N-QL for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 20:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Oct 2013 00:15: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.138257365831136 (code B ref 15648); Thu, 24 Oct 2013 00:15:02 +0000 Original-Received: (at 15648) by debbugs.gnu.org; 24 Oct 2013 00:14:18 +0000 Original-Received: from localhost ([127.0.0.1]:39316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZ8Z7-000867-IJ for submit@debbugs.gnu.org; Wed, 23 Oct 2013 20:14:18 -0400 Original-Received: from vms173007pub.verizon.net ([206.46.173.7]:39116) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZ8Z5-00085u-3W for 15648@debbugs.gnu.org; Wed, 23 Oct 2013 20:14:15 -0400 Original-Received: from consult.pretender ([unknown] [72.93.211.25]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MV5002WPCN5X9H0@vms173007.mailsrvcs.net> for 15648@debbugs.gnu.org; Wed, 23 Oct 2013 19:13:54 -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 r9O0DqV5031841; Wed, 23 Oct 2013 20:13:52 -0400 0;136;0cTo: In-reply-to: <21096.24492.292723.589004@consult.pretender> 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:79560 Archived-At: emacs@kosowsky.org wrote at about 19:45:48 -0400 on Wednesday, October 23, 2013: > 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... Just one addendum... If the maintainers of gnutls.el for some presumably unstated by compelling reason do not want to support Magic File names (aka file handlers), then the library code should: 1. Properly disable the use of file handlers so that modified primitives (like file-exist-p) fail on cygwin paths. One way would be to add the following line to the let* statement in gnutls-negotiate: (file-name-handler-alist nil) 2. DOCUMENT that gnutls doesn't support Magic File names