In gnupg/agent/findkey.c, we have a function try_unprotect_cb.
It is called by agent_askpin as a callback.
But, it may be called with ENTRY_LOCK held.
When try_unprotect_cb calls agent_get_confirmation, recursive lock of ENTRY_LOCK occurs.
Description
Description
Revisions and Commits
Revisions and Commits
| rG GnuPG | |||
| rG3924e1442c66 agent: Clean up pinentry access locking. | |||
| rG4738256f2e0d agent: Allow recursive use of pinentry. | |||
| rGfb7828676cc2 agent: Clean up pinentry access locking. | |||
| rG3b66a256e376 agent: Allow recursive use of pinentry. | |||
Related Objects
Related Objects
- Mentioned Here
- rG3b66a256e376: agent: Allow recursive use of pinentry.
Event Timeline
Comment Actions
The obvious fix to unlock and relock the pinentry during the callback would have the problem that instead of the confirmation request a pinentry from another connection may pop up. That would be quite confusing.
So, what about checking whether the same connection invokes the pinentry recursive and allow for that? With a counter to detect missing unlocks etc.
Comment Actions
OK, I can make reproducible error case:
$ export GNUPGHOME=/tmp/gpg $ mkdir -m=0700 $GNUPGHOME $ gpg-agent --faked-system-time=1508900000 --daemon /bin/bash $ gpg --yes --quick-gen-key "chuji@gniibe.org" [ ENTERING PASSPHRASE for creation of the key ] $ exit $ gpg-agent --max-passphrase-days=1 --daemon /bin/bash $ touch example.txt $ gpg --clear-sign example.txt [ Enter passphrase ] [ Then, it hang ]
Comment Actions
rG3b66a256e376: agent: Allow recursive use of pinentry. fixes the test case above.
I wish it doesn't cause any other issues.