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