Including .gpg extension causes unintended results when calling fscopy

[tjex]

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

[tjex]

@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)

[dominikschulz]

@tjex Of course, go ahead and reach out on Slack if you need help.

[dominikschulz]

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 or entry is not in the password store. If you want me to keep investigating this I'd need a log file. Set GOPASS_DEBUG_LOG=/tmp/gopass.log. Preferrably with an empty/mock password store so you don't leak anything confidential.

[tjex]

@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

[leogott]

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?

[dominikschulz]

Absolutely. We should see what we can do to avoid this failure mode.

[dominikschulz]

@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:

1. 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
2. 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?