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).
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).