gopass
gopass copied to clipboard
Including .gpg extension causes unintended results when calling fscopy
Summary
It could also be worth looking at #2767 along with this issue, as they seem to be related.
the command gopass fscopy file.ext.gpg ~/dir/file.ext
results in file.ext.gpg
being copied (still encrypted) to a newly created folder $PASSWORD_STORE_DIR/dir
.
This results in $PASSWORD_STORE_DIR/file.ext.gpg
and $PASSWORD_STORE_DIR/dir/file.ext.gpg
.
Steps To Reproduce
cd $PASSWORD_STORE_DIR
touch ~/test-file.txt
gopass fscopy ~/test-file.txt ./test-file.txt
gopass fscopy ./test-file.txt.gpg ~/test-dir/test-file-dencrypted.txt
ls $PASSWORD_STORE_DIR
Notice how (on mac) there is a new Users/<user>/test-dir
directory with test-file-decrypted.txt.gpg
inside.
Expected behavior
An error message stating the requirement of fscopy
to be provided filenames without .gpg
extension, as well as a friendly notice that the user may be wanting to use gopass cp
instead.
Environment
- macos 13.5
- OS Version: Darwin tjex-lappy 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul 5 22:22:05 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000 arm64
- gopass Version: gopass 1.15.11 go1.21.4 darwin arm64
- Installation method: brew
Additional context
@dominikschulz I don't mind having a look at this one first if you like?
(I would most likely be asking for some minor pointers via slack though)
@tjex Of course, go ahead and reach out on Slack if you need help.
I'm afraid but I can't reproduce your issue:
- You shouldn't run gopass inside of
$PASSWORD_STORE_DIR
. This is neither tested nor supported. It will mostly work, but especially fscopy (and some other commands) check if either source or destination files exist to resolve ambiguity. This doesn't work properly if you run gopass in the password store directly. - Most commands fail for me with
Error: ambiguity detected. Only from or to can be a file
orentry is not in the password store
. If you want me to keep investigating this I'd need a log file. SetGOPASS_DEBUG_LOG=/tmp/gopass.log
. Preferrably with an empty/mock password store so you don't leak anything confidential.
@dominikschulz I'm not using the ENV variable in a command. Here is the ascii cast again (also posted in #2767
https://asciinema.org/a/4Ly7KK729pDh3YWFGtNndfmci
today I ran into a different issue that was caused by running gopass in my password store dir. (resulted in creating a secret.gpg.gpg file) It might be a good idea to have some safeguards in place / display a warning when gopass is run inside the store or a filename is specified instead of the name of a secret?
Absolutely. We should see what we can do to avoid this failure mode.
@leogott I fail to reproduce what you've been doing there. Could you provide the command(s) you used?
@tjex I still struggle to understand how you came up with the sequence of commands but I think we can be more helpful.
I have tried to reproduce this and came to slightly different results, however.
$ export GOPASS_HOMEDIR=/tmp/gopass
$ gopass setup
$ touch /tmp/test-file.txt
$ gopass fscopy /tmp/test-file.txt ./test-file.txt # (1)
$ cd /tmp/gopass/.local/share/stores/root/
$ ls
test-file.txt.gpg
$ gopass fscopy ./test-file.txt.gpg /tmp/test-file-dec.txt # (2)
$ ls
test-file.txt.gpg tmp
Notice how the second fscopy (incorrectly) placed the secret at tmp/test-file-dec.txt
within the store.
So I think some things to be improved here:
- We should not allow/use absolute locations as secret names. This should be rejected. The correct form would be
gopass fscopy /tmp/test-file.txt test-file.txt
- Actually same as 1. and addtionally we should at least warn if operating on source or destination files within the password store.
Anything else I've missed?
@leogott I fail to reproduce what you've been doing there. Could you provide the command(s) you used?
sure.
- don't have bash completions installed for gopass
- navigate to password-store
- try to run gopass insert secret key (e.g.
gopass insert Account/example.org url
), but press tab on a partial secret name resultign in [secret].gpg
result: a new file secret.gpg.gpg is created, while secret.gpg remains unmodified
In my case I guess the snag point with these commands is remembering that when invoking gopass
in the shell, that when encrypting, the "to" file doesn't need an absolute or relative path from the cwd. i.e, it is written as if the user is already in the password_store_dir
, but also without writing as such: ./dir-in-store/secret
. Which can be a matter of habit.
In any case, thanks for the fix!