https://bugs.kde.org/show_bug.cgi?id=458085
--- Comment #61 from Thiago Macieira <thi...@kde.org> --- (In reply to michaelk83 from comment #60) > 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). That is understood. I did say that my idea would only work if there were a way to break the loop. If there isn't, then it doesn't help. > 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. Only if it got coded this poorly. A proper implementation would realise that the request for GPG to open the wallet is still pending and queue the request to be answered when the wallet got opened. So the loop breaks, but doesn't solve the problem. > > 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. It also wouldn't work if I had my ~/.gnupg directory protected against unwanted reads and writes. I really think we need to talk to the gpg-agent/pinentry folks. -- You are receiving this mail because: You are watching all bug changes.
