~/.cache/gopass/gpg-binary.loc is storing an absolute path to gpg, which overrides the environment $PATH

[siriobalmelli]

Summary

~/.cache/gopass/gpg-binary.loc is storing an absolute path to the gpg executable, which overrides the environment $PATH.

Steps To Reproduce

Config file:

---
autoclip: true
autoimport: true
cliptimeout: 45
exportkeys: true
mime: true
nocolor: false
nopager: false
notifications: true
path: /Users/[my_user_name]/.password-store
safecontent: true
mounts: {}

export PATH=/unusual/path/to/gnupg/bin
gopass  my-password  # this works
mv /unusual/path/to/gnupg/bin /unusual/path2/to/gnupg/bin
export PATH=/unusual/path2/to/gnupg/bin
gopass  my-password  # breaks with 'Decryption failed: fork/exec /unusual/path/to/gnupg/bin/gpg'
rm ~/.cache/gopass/gpg-binary.loc
gopass  my-password  # this works again

Expected behavior

Any UNIX program should always respect the contents of $PATH

Environment

• OS: Mac OS X Catalina
• OS version: Darwin computer.home 19.6.0 Darwin Kernel Version 19.6.0: Thu Oct 29 22:56:45 PDT 2020; root:xnu-6153.141.2.2~1/RELEASE_X86_64 x86_64 i386 MacBookPro16,1 Darwin
• gopass Version: gopass 1.10.1+af9c95d20b722dee331adcc3cc1ab1ce0108dc2b (af9c95d20b722dee331adcc3cc1ab1ce0108dc2b) go1.15.6 darwin amd64
• Installation method: Nix, building the latest build from source

[dominikschulz]

This file is used as an optimization for the awkwardly slow gpg operations we had before.
I guess a proper implementation wouldn't suffer from the limitations and wouldn't need this workaround, but we carry some cruft there. So for the time being this is a wont-fix, but ultimately you are right of course: we must respect $PATH.

[siriobalmelli]

I understand the problem, and I see it's a difficult engineering tradeoff to make.

Unfortunately, Nix is very broken by this failure to respect $PATH, so I am forced to work around it by calling rm -f "${XDG_CONFIG_HOME:-~/.config}/gopass/gpg-binary.loc" before every invocation of gopass.

May I make a couple suggestions?

The Ideal Case

Ideally, there is a solution which can be found which will respect $PATH.

This is also a possible security issue because if a serious vulnerability is patched in gpg in the future and the patched gpg is installed in a different location, this program would continue using the old gpg until it was removed (which may never happen on a production system).

It is worth mentioning that even when I am deleting the cache file before each time gopass is run, I am still seeing fast response times:

$ time rm -f "${XDG_CONFIG_HOME:-~/.config}/gopass/gpg-binary.loc" && gopass show -C my_password
Entry 'my_password' not found. Starting search...
Found exact match in 'my_folder/my_password'
✔ Copied my_folder/my_password to clipboard. Will clear in 45 seconds.
login: user_name
password: ********


real	0m0.377s
user	0m0.169s
sys	0m0.263s

By not maintaining the cache file in the first place, this would actually be (slightly) faster.

Perhaps there is a clever solution which leverages the parallelism of Go to search all components of $PATH for the gpg binary at the same time?

The Patch Case

If, after evaluating the above, the decision is still wont-fix, would you at least consider a fall-back path in the code, where:

• the cached binary is no longer found (error)
• fall back to searching $PATH and, if finding a gpg binary, update the cache

This is not ideal because it still breaks a basic invariant on how programs should behave with $PATH (it took me a while to find this bug - I really was not expecting for $PATH to be ignored!), but at least it stops gopass from failing because of a "missing" gpg when there is a valid gpg in $PATH.

[dominikschulz]

@siriobalmelli Thank you for detailing your reasoning. Please have a look at #1684 and let me know what you think.

[siriobalmelli]

This seems like the right way to go, I appreciate your work on this 😄

I'll keep this open until #1684 goes through and then I'll test on my end also.

[siriobalmelli]

Looking good, thank you again @dominikschulz for your assistance getting this sorted.