https://bugs.kde.org/show_bug.cgi?id=458085
Thiago Macieira <thi...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |thi...@kde.org
--- Comment #57 from Thiago Macieira <thi...@kde.org> ---
I disagree that no-allow-external-cache is a proper solution. It's a
workaround, but it prevents one from using GPG/pinentry for other tasks and
saving the credential cache in the KWallet-provided Secret Service. It's
probably the least-intrusive option because gpg-agent does caching on its own
anyway, but it's not a solution.
The solution would be to make kwalletd be able to answer this query coming from
pinentry. To do that, make the kwalletd code asking for the unlocking of GPG
wallet not block - if there's an asynchronous API for that, you can use it,
otherwise move the entire workload to a separate thread. QtDBus is already
threaded, so the query was received by the the process; however, the thread
owning the QObject that would've answered the call was blocked and didn't
answer.
You need to make sure this doesn't loop again: make sure this Secret Service
call isn't going to trigger another call back to pinentry and thus loop again.
This has the added benefit that kwalletd isn't frozen while pinentry is waiting
for the user to type the password. I've seen before that applications waiting
for kwalletd also freeze if kwalletd won't answer, though this particular
change may not affect the applications that are freezing, if kwalletd can't
answer the call in the first place. This benefit comes with its drawback
though: kwalletd needs to know that it's already waiting for the wallet to open
and queue the reply going back to the application.
--
You are receiving this mail because:
You are watching all bug changes.
