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 with earlier versions and AFAIK no way to elicit the original behaviour from gpg.
Additional info:
- system: Arch Linux, updated on 09/12/2023
- package version (as per Arch's repositories): v2.4.3-2 (reverting to v2.2.41-2 immediately fixes it for me)
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.