v2.4.3-2 unnecessarily prompts on multi-key encryption despite 1st key being unlocked
Description:
After updating to v2.4.3-2 I noticed that pass
would keep pestering me for my private key which encrypts all my passwords despite a subset of those passwords being encrypted against a local key which is unlocked on login. Refusing to give the password, would still lead to successful decryption as the other key is still attempted.
After a bit of investigation it seems this is gnupg
's fault.
This may be related to the order in which gpg keeps the keys in the keyring too I guess. There is still a behaviour difference between the versions and AFAIK no way to elicit the original behaviour from gpg.
Additional info:
- package version(s): v2.4.3-2 (reverting to v2.2.41-2 immediately fixes it for me)
- link to upstream bug report, if any: https://dev.gnupg.org/T6873
Steps to reproduce:
This is expected and same as in v2.2:
gpg --e -r locked@key -r unlocked@key file > file.gpg
-
gpg --d file.gpg
will prompt for the locked key, but it will still use the unlocked key if the prompt is refused.
However,
gpg --e -r unlocked@key -r locked@key file > file.gpg
-
gpg --d file.gpg
should decrypt with the unlocked key without ever prompting for the locked one, but I see no behaviour change.
Note: in case it matters, the above was tested with the locked key appearing above the locked one on gpg -K
.