From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.bugs Subject: bug#15866: Gnutls elisp code doesn't properly check for file existence Date: Tue, 12 Nov 2013 13:12:52 -0500 Message-ID: <21122.28580.612896.572445@consult.pretender> References: <21121.29752.814965.329395@consult.pretender> <83ob5p1pgd.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 1384280059 18783 80.91.229.3 (12 Nov 2013 18:14:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Nov 2013 18:14:19 +0000 (UTC) Cc: 15866@debbugs.gnu.org, emacs@kosowsky.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 12 19:14:22 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 1VgITj-00044I-6B for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Nov 2013 19:14:19 +0100 Original-Received: from localhost ([::1]:44550 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgITi-0001Ab-Mt for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Nov 2013 13:14:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58674) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgITY-00012A-My for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2013 13:14:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VgITS-0001bQ-Dt for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2013 13:14:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35077) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgITS-0001bK-99 for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2013 13:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VgITR-0000dq-Rt for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2013 13:14:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Nov 2013 18:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15866 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15866-submit@debbugs.gnu.org id=B15866.13842800232435 (code B ref 15866); Tue, 12 Nov 2013 18:14:01 +0000 Original-Received: (at 15866) by debbugs.gnu.org; 12 Nov 2013 18:13:43 +0000 Original-Received: from localhost ([127.0.0.1]:49096 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VgIT9-0000dC-AD for submit@debbugs.gnu.org; Tue, 12 Nov 2013 13:13:43 -0500 Original-Received: from vms173011pub.verizon.net ([206.46.173.11]:50651) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VgIT7-0000cw-4m for 15866@debbugs.gnu.org; Tue, 12 Nov 2013 13:13:41 -0500 Original-Received: from consult.pretender ([unknown] [96.237.159.120]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MW50000XX9HX2U1@vms173011.mailsrvcs.net> for 15866@debbugs.gnu.org; Tue, 12 Nov 2013 12:13:09 -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 rACICq2C006781; Tue, 12 Nov 2013 13:12:53 -0500 In-reply-to: <83ob5p1pgd.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:80340 Archived-At: Eli Zaretskii wrote at about 19:48:18 +0200 on Tuesday, November 12, 2013: > > Date: Mon, 11 Nov 2013 19:20:08 -0500 > > From: "" > > > > i] If the function 'expand-file-name' has an associated magic file > > handler, the function expand-file-name is called to convert it "to > > absolute, and canonicalize it" (quoted from the function > > definition). > > > > ii] The test for file-exists-p is then wrapped in a 'let' construct > > with file-name-handler-alist set to nil. This effectively shuts > > off magic file handling and ensures that file-exists-p now checks > > for true OS existence of the now potentially expanded path. > > > > iii]The function gnutls-trustfiles is now assured that it will be > > passed an OS-valid path. > > Thanks. > > As I wrote elsewhere, I agree that gnutls.el should ignore file > handlers when it looks for certificate files. > > But then _not_ ignoring the expand-file-name handler makes little > sense to me: the result could exist as a local file name that has no > relation whatsoever to certificates, which will again fail in strange > ways inside the GnuTLS library. > > So I think we should do ii], but not i]. As I mentioned many times, I would find that an acceptable even if minimal and non-ideal (for me) solution - provided that it also were documented in the elisp file and probably also in the gnutls-trustfiles variable that magic file handling is shut off for this variable. I am ok with that. I also think that the following two usability messages should be added: 1. Warning message (but perhaps not error) triggered if no elements of gnutls-trustfiles are valid files 2. Trapping of error if for some reason file-exists-p shows the file to exist but for some reason gnutls still can't access it. In summary, my primary issue was with you declaring the bug summarily closed when the code clearly was inconsistent in allowing magic file handling for file-exists-p while not passing on such handling to the c-routines that actually access the file. Indeed, while one can disagree with *how* a bug is fixed and to what extent one goes to fix it, one shouldn't ignore the presence of a bug or sloppy code when such a simple fix exists. While it might make little (logical) sense to put ange-ftp or tramp style paths in gnutls-trustfiles, if one did, they too would cause this routine to error out. Hence the coding inconsistency is not limited to cygwin-mount even though the chances of it surfacing outside of cygwin-mount may be quite small. So, let's at least agree to the minimal fix for now... I will address my comments on the pluses/minuses of persistence of cygwin-mount in response to your other message... > Btw, I think many Emacs packages don't make sense with remote files, > so they should also ignore file handlers. IOW, this is not specific > to gnutls.el.