Hello there,I ran into an issue with gpg 2.3.7 that causes pass init to fail to re-encrypt a random subset of passwords. The error message is as follows.
gpg: release_dotlock: not our lock (pid=2013175) gpg: can't unlock '/home/louis/.gnupg/pubring.kbx' gpg: encrypted with rsa2048 key, ID CBACA7AF7D2E9CB6, created 2022-12-03 "Louis Bettens <[email protected]>"I have been able to narrow it down to line 136 and to the pattern of piping gpg -d into gpg -er [...]. This is a race condition where sometimes the second process will acquire the lock after the first and cause it to complain. Importantly, the pipeline still outputs a correct PGP message (I think) but one of the processes will exit with 2 which causes pass to skip that password.
I can reproduce the behavior in isolation by running echo test | gpg -er [email protected] | gpg -d and observe that, with some unknown probability, the second process will exit with 2 after printing the message. I am using NixOS 22.11 and a Nitrokey Pro, although this also occurs with keys stored on disk.
For possible fixes, I think the most straightforward would be to use $SECURE_TMPDIR. Of course this adds an requirement on the running environment (as well as a security assumption) but unless there is a simple way to sequence two commands in a pipeline and also ensure the pipe buffer doesn't fill up, this seems like the best approach. I can produce a patch if there is no objection.
Louis
OpenPGP_0xDFE1D4A017337E2A.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
