GNU bug report logs - #35241
27.0.50; Tramp can't decrypt .authinfo.gpg in Win 10

Previous Next

Package: emacs;

Reported by: Shuguang Sun <shuguang79 <at> qq.com>

Date: Fri, 12 Apr 2019 02:46:01 UTC

Severity: normal

Found in version 27.0.50

Done: Michael Albinus <michael.albinus <at> gmx.de>

Bug is archived. No further changes may be made.

Full log


Message #23 received at 35241 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Shuguang Sun <shuguang79 <at> qq.com>
Cc: 35241 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#35241: 27.0.50; Tramp can't decrypt .authinfo.gpg in Win 10
Date: Tue, 16 Apr 2019 14:50:40 +0200
Shuguang Sun <shuguang79 <at> qq.com> writes:

Hi,

>>>   tramp-file-name-handler(expand-file-name "." "/plink:username <at> host.com:")
>>>   locate-file-internal("gpg2" (list of path) (".exe" ".com" ".bat"
>>> ".cmd" ".btm" "") 1)
>>>   executable-find("gpg2")
>>
>> This is the crucial part. `executable-find' shall operate on the local
>> file system only. But it calls `locate-file-internal' with a PATH
>> pointing to remote.
>>
>> I suppose you have edited the backtrace, and written (list of path).
>> What is there? My crystal ball tells me it contains "." ...
>
> Sorry. I do modified it here. It is the local path, not remote. And it
> contains "." which looks like:
>
>   locate-file("gpg2" ("." "C:/Users/username/emacs/bin/" "C:/Users/username/scoop/apps/gnupg/current/bin/" "C:/Users/username/scoop/shims/" "C:/Users/username/Progs/msys64/mingw64/bin/" "C:/Users/username/Progs/msys64/usr/bin/" "C:/Users/username/Progs/miktex-portable/texmfs/insta..." "C:/Users/username/AppData/Local/Microsoft/WindowsApp...") (".exe" ".com" ".bat" ".cmd" ".btm" "") 1)

Thanks, as I've expected. A relative file name like "." is the
problem. If the current directory is a remote one, it expands to a
remote directory inside exec-path, with all the hassle.

How does come "." into exec-path? Have you set this in your .emacs? Or
is it part of the PATH environment variable on your system? You know,
that it is discouraged to add "." to your PATH for security reasons.

Relative file names are not forbidden as part of exec-path. Shall we ban
them (with an error message)? Or shall we ignore them, silently? Don't know.

I'd vote for the latter (including proper documentation).

Best regards, Michael.




This bug report was last modified 6 years and 37 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.