I use kwallet 4.13.3 with the GPG backend and configured it to automatically close the wallet after a certain period. When leaving the PC unattended for a while, after some time programs demand acces to the (now automatically closed) wallet, that's why I need to enter the password for my GPG key again. While only one instance of pinentry-qt is opened, over time multiple windows of "GPG-backend for kwallet" open and consume system resources. After entering the password in pinentry-qt, only one of them vanishes, the others hang/freeze. sverity: major, because it may cause the system to become unresponsible when using GPG backend
Created attachment 88130 [details] Screenshot of system with pinentry-qt4 dialogue and multiple instances of kwalletd GPG backend
Please configure and use gpg-agent. In such a setup the pinentry dialog pops only once per user session, as GPG-agent further maintain keys in memory. For example, you could use this this script in ~/.kde4/env: eval `gpg-agent --daemon`
Ok, I'm going to try this, but doesn't that mean that the unencrypted gpg key remains in memory the whole time? I configured kwallet to be closed after a certain time to prevent having it in memory unencrypted, and I don't want my gpg key lying around their either.
(In reply to spiollinux from comment #3) > Ok, I'm going to try this, but doesn't that mean that the unencrypted gpg > key remains in memory the whole time? I configured kwallet to be closed > after a certain time to prevent having it in memory unencrypted, and I don't > want my gpg key lying around their either. Well, I have no means to control the GPG behavior. The pinentry utility is prompted by GPG and by no means could it be controlled. The only solution is to kill the kwallet daemon. In fact, preventing pinentry window manipulation is actually a security measure. You may have noticed it's operating in session-modal mode. So I think you may really want to use gpg-agent. I'm actually using this setup without any problems. So for the moment I'll close this bug and please do not reopen it.
My problem isn't _that_ GPG backend for kwallet opens, my problem is that it opens _multiple times_! I won't reopen the bug, but please consider whether the current behaviour is the correct one. Thanks for your effort
(In reply to spiollinux from comment #5) > My problem isn't _that_ GPG backend for kwallet opens, my problem is that it > opens _multiple times_! > Oh, that's different and I now get your point. I suppose I could add some state and timeout logic in the daemon to handle this. Thanks for the suggestion. Stay tuned.
Created attachment 89276 [details] screenshot of flood of kwallet GPG retry/cancel dialogs
I also have this problem. I use an openPGP smartcard and have the wallet set to close automatically. When an application tries to read the wallet with the card disconnected, it fails, resulting in dozens of 'kwalletd GPG backend' retry/cancel dialogs. So if I leave it unattended for too long, KDE becomes unresponsive, so I can't unlock the screensaver. I have to restart KDM to continue using my computer. I attached a screenshot.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
I have switched to a GPG agent-based setup, so I am not sure whether I can reproduce the affected setup.
I can reproduce this, but it only opens twice here. My setup is using gpg-agent with a gpg encrypted wallet. * After logging in pintenry asks me to enter the password. * If this times the retry/cancel dialog is opened (see screenshots) and a second pinentry is opened to enter the password. If i enter the password here, the retry/cancel dialog is still present and needs to be closed. * If the second pinentry also times out, it creates a second retry/cancel dialog. No more pinentry is opened.
Created attachment 140249 [details] screenshot of retry dialog with second opened pinentry after first pintetry timed out
Created attachment 140250 [details] screnshot of two retry dialogs after two pinentry timeouts