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

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

[emacs]

The function gnutls-negotiate uses the (potentially)
magic-file-enabled predicate file-exists-p to check for the
"existence" of files in the gnutls-trustfiles list before passing the
raw file paths on as-is to the gnutls c-code.

The elements of the problem are as follows

1. The predicate file-exists-p potentially references
   magic-file-handler(s) so that we really are only testing for the
   existence of the magic-modified file path. At the same time the
   c-code is unaware of magic-file-handlers and assumes the raw path is a
   standard OS-accessible path without any magic modification.

   In particular, I have encountered this inconsistency with the
   cygwin-mount magic file handler, but the same problem will occur with
   *any* magic file handler that causes a non-OS recognizable path to
   test as existing with file-exists-p.

2. When the gnutls c-code is passed a file path that the OS can't find,
   it crashes the gnutls calling function without any human-readable or
   understandable error message. The error code passed back is "-64"
   whic presumably must mean something like "file not found"

3. Gnutls.el implicitly supports cygwin since a cygwin-style trustfile
   is included in gnutls-trustfiles and labeled as such. This presumably
   works fine in a cygwin-compiled version of emacs but if one uses a
   generic windows-native version of Emacs with cygwin-mount as the
   magic file handler then problems (1) & (2) cause gnutls to crash
   every time.

Luckily, there is a near trivial patch that does the following:

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.

--- gnutls.el	2013-03-17 13:52:40.000000000 -0400
+++ gnutls.el.new	2013-10-23 12:47:36.503554500 -0400
@@ -174,7 +174,8 @@
   (let* ((type (or type 'gnutls-x509pki))
          (trustfiles (or trustfiles
                          (delq nil
-                               (mapcar (lambda (f) (and f (file-exists-p f) f))
+                               (mapcar (lambda (f) 
+								   		   (and f 
+										     (if (find-file-name-handler f
												    'expand-file-name)
+								   		      		(setq f (expand-file-name f)))
+											  (let (file-name-handler-alist)
+                                              	   (file-exists-p f)) f))
                                        (if (functionp gnutls-trustfiles)
                                            (funcall gnutls-trustfiles)
                                          gnutls-trustfiles)))))


The patch could of course be extended to 'catch' any error and display
an error message like "Error: gntuls trustfile xxxxx not found" rather
than crashing if somehow there is still a file access issue.

I generate the error using the following:
(require 'cygwin-mount)
(require 'gnutls)
(open-gnutls-stream "tls" "tls-buffer" "imap.gmail.com" "imaps")

The emacs debugger, gives the following results:

Debugger entered--Lisp error: (gnutls-error #<process tls> -64)
  signal(gnutls-error (#<process tls> -64))
  gnutls-negotiate(:process #<process tls> :type gnutls-x509pki
  :hostname "imap.gmail.com")
  open-gnutls-stream("tls" "tls-buffer" "imap.gmail.com" "imaps")
  eval-region(19 83 t #[257 "\300\242b\210\301\207" [(83)
  (open-gnutls-stream "tls" "tls-buffer" "imap.gmail.com" "imaps")] 2
  "\n\n(fn IGNORE)"])  ; Reading at buffer position 83
  eval-defun-2()
  eval-defun(nil)
  call-interactively(eval-defun nil nil)
  command-execute(eval-defun)

--------------------------------------------------------------------------

In GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
 of 2013-03-17 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
  shell-dirtrack-mode: t
  display-time-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  auto-fill-function: do-auto-fill
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
<backspace> <backspace> <backspace> <backspace> <backspace> <tab> r <tab> <return>

Recent messages:
Quit
Deleting...done
(No files need saving)
Marking holidays...done
Marking holidays...done
Undo!
Mark saved where search started [2 times]
Making completion list... [3 times]
delete-backward-char: Text is read-only [2 times]
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort emacsbug echistory chistory solar cal-dst cal-julian
cal-hebrew holidays hol-loaddefs cal-move cal-tex jjk-calendar cal-menu
calendar cal-loaddefs dired-aux browse-url url-util url-parse url-vars
ruler-mode hl-line hexl eldoc mule-util tramp-cmds noutline outline
easy-mmode tramp-cache tramp-sh tramp tramp-compat tramp-loaddefs shell
pcomplete find-func ebuff-menu pp misearch multi-isearch nxml-uchnm
rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc rng-uri
rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns
nxml-mode nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc xmltok
network-stream starttls tls message idna format-spec mml mml-sec
mm-decode mm-bodies mm-encode gmm-utils mailheader vm-imap bbdb-gui
help-mode flyspell ispell cl-macs gv vm-reply easymenu jjk-vm dired
vm-mime-display-internal-application vm-ps-print bbdb-vm vm-autoload
bbdb-snarf mail-extr rfc822 bbdb-autoloads bbdb-hooks mail-parse rfc2231
bbdb-com mailabbrev cl vcard vm-vcard vm-pine smtpmail bbdb timezone
sendmail rfc2047 rfc2045 ietf-drums mail-utils vm-rfaddons vm-menu
vm-window vm-toolbar vm-folder vm-mime vm-undo vm-virtual
vm-summary-faces vm-summary vm-mouse vm-page vm-motion vm-minibuf
vm-message vm-misc vm-macro vm-autoloads vm-vars vm-version vm
jjk-comments jjk-load ps-print ps-def lpr jjk-print ibm-keymaps
jjk-frames jjk-hooks jjk-keymaps ehelp electric uniquify warnings
arc-mode archive-mode jjk-lib epa-file epa derived epg epg-config advice
help-fns cl-lib advice-preload auth-source eieio byte-opt bytecomp
byte-compile cconv gnus-util mm-util mail-prsvr password-cache
cygwin-mount ange-ftp comint ansi-color ring server time time-date
tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process w32 multi-tty emacs)

In GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
 of 2013-03-17 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
  shell-dirtrack-mode: t
  display-time-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  auto-fill-function: do-auto-fill
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
<tab> r <tab> <return>

Recent messages:
Quit
Deleting...done
Undo!
Mark saved where search started [2 times]
Making completion list... [3 times]
delete-backward-char: Text is read-only [2 times]
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort emacsbug echistory chistory solar cal-dst cal-julian
cal-hebrew holidays hol-loaddefs cal-move cal-tex jjk-calendar
cal-menu calendar cal-loaddefs dired-aux browse-url url-util url-parse
url-vars ruler-mode hl-line hexl eldoc mule-util tramp-cmds noutline
outline easy-mmode tramp-cache tramp-sh tramp tramp-compat
tramp-loaddefs shell pcomplete find-func ebuff-menu pp misearch
multi-isearch nxml-uchnm rng-xsd xsd-regexp rng-cmpct rng-nxml
rng-valid rng-loc rng-uri rng-parse nxml-parse rng-match rng-dt
rng-util rng-pttrn nxml-ns nxml-mode nxml-outln nxml-rap nxml-util
nxml-glyph nxml-enc xmltok network-stream starttls tls message idna
format-spec mml mml-sec mm-decode mm-bodies mm-encode gmm-utils
mailheader vm-imap bbdb-gui help-mode flyspell ispell cl-macs gv
vm-reply easymenu jjk-vm dired vm-mime-display-internal-application
vm-ps-print bbdb-vm vm-autoload bbdb-snarf mail-extr rfc822
bbdb-autoloads bbdb-hooks mail-parse rfc2231 bbdb-com mailabbrev cl
vcard vm-vcard vm-pine smtpmail bbdb timezone sendmail rfc2047 rfc2045
ietf-drums mail-utils vm-rfaddons vm-menu vm-window vm-toolbar
vm-folder vm-mime vm-undo vm-virtual vm-summary-faces vm-summary
vm-mouse vm-page vm-motion vm-minibuf vm-message vm-misc vm-macro
vm-autoloads vm-vars vm-version vm ehelp electric uniquify warnings
arc-mode archive-mode epa-file epa derived epg epg-config advice
help-fns cl-lib advice-preload auth-source eieio byte-opt bytecomp
byte-compile cconv gnus-util mm-util mail-prsvr password-cache
cygwin-mount ange-ftp comint ansi-color ring server time time-date
tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process w32 multi-tty
emacs)

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

[Eli Zaretskii]

> Date: Mon, 11 Nov 2013 19:20:08 -0500
> From: "" <emacs@kosowsky.org>
> 
> 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].

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.

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

[emacs]

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

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

[Ted Zlatanov]

On Tue, 12 Nov 2013 13:12:52 -0500 <emacs@kosowsky.org> wrote: 

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

Great.  Could you test and submit the patch with just that piece [ii]
and I'll commit it, then add the documentation?

> 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

Good idea, I'll add it with the docs.

> 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.

I'm not sure this should be trapped at that level.  It feels like
something that should be bounced up to the user, as it could indicate
serious system problems or some suspicious (possibly malicious)
tinkering with the file calls.

>> 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.

Right, hence my concern about doing these fixes just for gnutls.el.  It
seems like a general problem.

Ted

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

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> As I wrote elsewhere, I agree that gnutls.el should ignore file
> handlers when it looks for certificate files.

The canonical way to ignore any file name handler is to prefix the file
name with "/:", see (info "(emacs)Quoted File Names")

Best regards, Michael.

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

[Stefan Monnier]

>> As I wrote elsewhere, I agree that gnutls.el should ignore file
>> handlers when it looks for certificate files.

> The canonical way to ignore any file name handler is to prefix the file
> name with "/:", see (info "(emacs)Quoted File Names")

That's the canonical way *for the user* to write a file that bypasses
file name handlers (useful when you want to access a local file named
/ssh:foo:bar, for example).

Whereas in gnutls.el the issue is for the *code* to check that the
libgnutls C code (which will not have access to the file name handlers)
will be able to use the file name provided by the user.


        Stefan

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

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Whereas in gnutls.el the issue is for the *code* to check that the
> libgnutls C code (which will not have access to the file name handlers)
> will be able to use the file name provided by the user.

Wouldn't a solution here be to introduce a variable like
`inhibit-file-handlers' that would really inhibit all Lisp-level file
handlers?  Doesn't Emacs have that already?  Hm...
`inhibit-file-name-handlers' doesn't quite seem to do the trick, I
guess?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: Michael Albinus <michael.albinus@gmx.de>,  15866@debbugs.gnu.org,  Eli Zaretskii <eliz@gnu.org>,  emacs@kosowsky.org
> Date: Sun, 07 Dec 2014 21:17:21 +0100
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > Whereas in gnutls.el the issue is for the *code* to check that the
> > libgnutls C code (which will not have access to the file name handlers)
> > will be able to use the file name provided by the user.
> 
> Wouldn't a solution here be to introduce a variable like
> `inhibit-file-handlers' that would really inhibit all Lisp-level file
> handlers?

How is that different from binding file-name-handler-alist to nil?

And btw, most file handlers are invoked on the C level, not the Lisp
level.

> `inhibit-file-name-handlers' doesn't quite seem to do the trick, I
> guess?

Not conveniently, no.

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

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Wouldn't a solution here be to introduce a variable like
>> `inhibit-file-handlers' that would really inhibit all Lisp-level file
>> handlers?
>
> How is that different from binding file-name-handler-alist to nil?

I guess it isn't.  Wouldn't that solve this problem?  The patch
presented did some stuff with

(if (find-file-name-handler f 'expand-file-name)
  ...

but perhaps just binding that variable to nil unconditionally would be
the right thing here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca,  michael.albinus@gmx.de,  15866@debbugs.gnu.org,  emacs@kosowsky.org
> Date: Sun, 07 Dec 2014 22:15:23 +0100
> 
> perhaps just binding that variable to nil unconditionally would be
> the right thing here?

AFAIR, that was the conclusion.

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

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
>> Cc: monnier@iro.umontreal.ca, michael.albinus@gmx.de,
>> 15866@debbugs.gnu.org, emacs@kosowsky.org
>> Date: Sun, 07 Dec 2014 22:15:23 +0100
>> 
>> perhaps just binding that variable to nil unconditionally would be
>> the right thing here?
>
> AFAIR, that was the conclusion.

Likely, yes.

I don't know whether there will be a certificate file ca.gpg, which is
protected by GPG, and which would not be accessible then. But due to the
nature of certificates they shall be readable, so maybe we can ignore
such a case.

Best regards, Michael.

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

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
>> Cc: monnier@iro.umontreal.ca, michael.albinus@gmx.de,
>> 15866@debbugs.gnu.org, emacs@kosowsky.org
>> Date: Sun, 07 Dec 2014 22:15:23 +0100
>> 
>> perhaps just binding that variable to nil unconditionally would be
>> the right thing here?
>
> AFAIR, that was the conclusion.

Ok; I've now applied something that binds that variable.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Michael Albinus]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Wouldn't a solution here be to introduce a variable like
> `inhibit-file-handlers' that would really inhibit all Lisp-level file
> handlers?  Doesn't Emacs have that already?  Hm...
> `inhibit-file-name-handlers' doesn't quite seem to do the trick, I
> guess?

`inhibit-file-name-handlers' is always used in conjunction with
`inhibit-file-name-operation'. Their purpose is to prevent recursive
call of a file name handler. So it isn't appropriate here.

Just for the records ...

Best regards, Michael.

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

[Stefan Monnier]

> So I think we should do ii], but not i].

Please go ahead, yes.

> 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.

Not sure how widespread this problem is.  At least the gnutls case is
rather special since most other C calls that manipulate files are
wrapped with a magic file handler.

But please do submit the other cases you bump into for consideration.


        Stefan

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

[Ted Zlatanov]

On Tue, 12 Nov 2013 15:02:40 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> So I think we should do ii], but not i].
SM> Please go ahead, yes.

>> 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.

SM> Not sure how widespread this problem is.  At least the gnutls case is
SM> rather special since most other C calls that manipulate files are
SM> wrapped with a magic file handler.

I am also thinking now about the FFI work (yes, it's somewhere on my
TODO list) and how these issues will be handled there.  It seems that
the FFI glue may have to tag filenames distinctly from plain strings and
may even have some file existence checks and hooks.

Ted

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

[Stefan Monnier]

> I am also thinking now about the FFI work (yes, it's somewhere on my
> TODO list) and how these issues will be handled there.  It seems that
> the FFI glue may have to tag filenames distinctly from plain strings and
> may even have some file existence checks and hooks.

I don't think the FFI should do that, no.  At least, for starters we'll
let each and every binding for a particular library deal with the
problem on a case-by-case basis.  And if/when this shows up repeatedly,
we can provide helper functions that give a "standard solution".


        Stefan