Version: 0.17.0-1
Severity: normal
Tags: upstream fixed-upstream
Hi,
Since 0.16.0, isKwalletAvailable() in qtkeychain/keychain_unix.cpp makes a
blocking call to org.kde.KWallet.networkWallet with the default 25 second
D-Bus timeout. It runs inline on the first keychain job, which is usually the
application's GUI thread, so the application freezes until the call times out.
kwalletd stops answering application-level D-Bus calls while an unlock dialog
is open for any client. That happens at login when the wallet password differs
from the login password, because kwallet-pam can't open the wallet. Several
autostarted applications can then ask for it at once, and any that probe
behind the dialog stall. In plasmashell that freezes the whole shell.
With the wallet locked and a dialog opened by another client, I measured:
org.freedesktop.DBus.Peer.Ping 0 ms reply
org.kde.KWallet.networkWallet 25301 ms NoReply
A Qt event loop with a 100 ms heartbeat went 25305 ms between ticks, so that
call accounts for the whole freeze.
Upstream fixed it by probing with org.freedesktop.DBus.Peer.Ping instead. The
QtDBus layer answers Ping, and it still triggers D-Bus activation.
commit: https://github.com/frankosterfeld/qtkeychain/commit/007abb86535c6e112d7c0d32ad5372302619b509
PR: https://github.com/frankosterfeld/qtkeychain/pull/304
issue: https://github.com/frankosterfeld/qtkeychain/issues/303
No tagged release has it yet. Once this has a bug number I'll send the commit
as a quilt patch against 0.17.0.
I reproduced this on Kubuntu 26.10 with kwalletd6 4:26.08.0-0ubuntu1 and
libqt6keychain1 0.17.0-1. I haven't run it on Debian. Testing and unstable
have the same qtkeychain 0.17.0-1, so I expect the same behaviour, but that
comes from the version number, not a test. Debian 13 has 0.15.0, which
predates the regression.
Full analysis and repro steps are in the Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/qtkeychain/+bug/2165214
Thomas Moore (realstuffie)