Page MenuHome GnuPG

v2.4 unnecessarily prompts on multi-key encryption despite 1st key being unlocked
Open, NormalPublic



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:

  1. gpg --e -r locked@key -r unlocked@key file > file.gpg
  2. gpg --d file.gpg will prompt for the locked key, but it will still use the unlocked key if the prompt is refused.


  1. gpg --e -r unlocked@key -r locked@key file > file.gpg
  2. 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.

Event Timeline

This comment has been deleted.

This seemed to be related to T6831 but here we have the case of different keys and not just different subkeys.