See T2196#206203 for the current description of the bug.
The former description was:
In keydb.c:lock_all, gpg locks all of the keyrings / keyboxes in the order that
they are added. This can result in deadlock if multiple gpg processes add the
keyrings / keyboxes in different orders.
The solution to this is straightforward: take the locks according to some
standard ordering (e.g., lexicographical).
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Testing | None | T2196 keydb locking can result in deadlock in 2.2 | ||
| Testing | • gniibe | T7855 keybox/keydb locking issue in 2.6 | ||
| Testing | • gniibe | T7805 Permission denied on batch deletion of mixed (openpgp+smime) certs |
We have never seen a real-world bug here. Thus I change this to a minor-bug.
You solution is not that easy becuase we need to maintain that order for all
time and we can't cope with older gpg versions which are still in use on the
same ~/.gnupg - they would have a different lock order and that would indeed
lead to a deadlock. As of now this is mitigated by all gpg versions using the
same config file and thus the same order of keyrings.
The upgrade path problem could be alleviated by this: Add support for a new locking order to gnupg, but don't use it by default. Then, after a couple of years, activate the new locking order in the configuration, so that systems with multiple versions of gnupg installed use the same locking order as long as none of the used versions is too old.
The other thing is to allow only one keyring, or better, use a central key daemon to access keys (kind of local keyserver).
We recently noticed problem at a customer site with creating the standard rsa3072 keys. It basically stopped working. A likely cause for this seems to be some anti-malware software slowing down file system calls. In the wake of this we looked again at our file locking strategy and found a few things which are not as they should be. For example the release of the lock before a Close call. Trying to fix this unfortunately caused other problems, thus a couple of fixes are needed.
[The original description of the bug is not relevant because we have only one resource, but the bug title is appropriate and thus we re-use this ticket.]