[BUG] Copy functionality failes to retrieve password when GnuPG key wasn't unlocked earlier

[AntonVanAssche]

What is the bug?

When attempting to use the --copy option in BashPass-Remote, if the GnuPG key has not been unlocked on the server beforehand, the program will not prompt the user to enter the password like it does with the --list option. Instead, it will continuously attempt to decrypt the password file until it fails. Once it fails, the program will write an empty string to the clipboard instead of the correct password.

How can one reproduce the bug?

First we have to make sure that it will prompt us for a password. We can do this by executing the command below. No worries, gpg will start again by itself.

$ ssh -t <user>@<host> "gpgconf --kill gpg-agent"

Now we can try to retrieve the password and write it to our clipboard.

$ bashpass-remote <user>@<host> -c <password-name>

What is the expected behavior?

When the user tries to retrieve a password from the server using BashPass-Remote, it will prompt them to enter their GnuPG key password if it has not been unlocked before. This behavior is similar to that of the --list option, which also prompts the user for their password. Once the password is entered correctly, BashPass-Remote will successfully retrieve the password from the server and function as intended.

Do you have any screenshots?

• Current behavior (sped up, as it takes more than a minute to finish):

• Intended behavior (from the --list option):

[AntonVanAssche]

If we try to print out the password variable, it will literally print out the GnuPG prompt. So we just need to find a way to avoid this.

password=$(ssh -t "${user}@${host}" '$(command -v bashpass) --show' "${1}") || \
    error_out "failed to retrieve password '${1}' from remote" 1

printf '%s\n' "${password}"
password=${password#*: }
printf '%s\n' "${password}"