bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15866: Gnutls elisp code doesn't properly check for file existence


From: emacs
Subject: bug#15866: Gnutls elisp code doesn't properly check for file existence
Date: Tue, 12 Nov 2013 13:12:52 -0500

Eli Zaretskii wrote at about 19:48:18 +0200 on Tuesday, November 12, 2013:
 > > Date: Mon, 11 Nov 2013 19:20:08 -0500
 > > From: "" <address@hidden>
 > > 
 > > 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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]