https://bugs.kde.org/show_bug.cgi?id=458085
--- Comment #60 from michaelk83 <mk.mat...@gmail.com> --- (In reply to Thiago Macieira from comment #59) > But the fact is that if the query was asynchronous, then pinentry would have > got its answer instead of timing out, and then would have prompted the user > for the password. Pinentry is asking for the passphrase through the same Secret Service API as any other client (see comment 31). KWallet has no way to tell it apart from any other client, so can't handle it differently. As far as KWallet can tell at this point, the passphrase that pinentry wants is inside the same wallet (but it's not). Currently pinentry's request blocks in the `OpenSession` call because KWallet is still waiting for GPG to unlock the wallet (for the original request of some other client app). If this was asynchronous, what would happen is KWallet would try to unlock the wallet a 2nd time to look for the passphrase there, which would invoke GPG and pinentry a 2nd time, which would ask KWallet again, and so on and on and on. > But do note I talked about KWallet ensuring it doesn't recurse infinitely, > which is why we'd need to figure out if where this particular password > could be saved if it is provided to KWallet; refusing to store it is a way to > break the chain. This is the passphrase for KWallet itself (or rather for the GPG key that encrypts the wallet). It's not stored anywhere. The cycle is when trying to retrieve it, not store it. But as noted above, as long as pinentry makes the request via the Secret Service API, KWallet has no way to know that it's its own password that is being requested here. > Your idea from comment 40 -- to tell gpg-agent that we want a password with > no-external-cache -- is a solution too. Probably the Right Solution (with > capital R and S). > > But not the way you described it. Modifying ~/.gnupg/gpg-agent.conf is not > acceptable, because it's not atomic. Yes, as I said, there could be timing issues and maybe other problems. That patch is still just an automated and time-limited workaround. I'm not aware of any other way to tell pinentry to not use the external cache, other than maybe by implementing the Assuan protocol. -- You are receiving this mail because: You are watching all bug changes.
