Bug 498695

Summary:	KWallet unlock dialogue timeouts when invoked through the Secret Service DBUS interface
Product:	[Frameworks and Libraries] frameworks-kwallet	Reporter:	scooter_icky238
Component:	general	Assignee:	Valentin Rusu <valir>
Status:	RESOLVED DOWNSTREAM
Severity:	normal	CC:	kde, kde, kdelibs-bugs-null, nate, nicolas.fella
Priority:	NOR
Version First Reported In:	6.9.0
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description scooter_icky238 2025-01-15 15:12:39 UTC

***
If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org

If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports

Please remove this comment after reading and before submitting - thanks!
***

SUMMARY

Using KWallet as the Secret Service provider, you have to respond very quickly to the password dialogue, or KWallet timeouts, keeps the password dialogue open, but returns an error to the application requesting access. This is very much not proper behavior. It causes, for example, all applications built using Chromium to forget their secrets, which means you lose access to your cookies and sessions.

I suspect this is an artificial, non-configurable delay implemented by KWallet, as neither Gnome Keyring Manager nor KeepassXC do this.

STEPS TO REPRODUCE
1. Install Chromium or an app built using the Electron framework. (VSCode, Spotify, Discord, etc.)
2. Close your KWallet wallet if it is open.
3. Open the application using Chromium.
4. *Do not* interact with the dialogue.

OBSERVED RESULT
Chromium will continue to launch after a period of time, disregarding the Secret Service API, and forgetting secrets.

EXPECTED RESULT
The password dialogue should indefinitely wait for the user. If the user has not interacted with the dialogue but the application is still waiting for a response, **KWallet should not timeout**.

SOFTWARE/OS VERSIONS
Windows:
macOS:
(available in the Info Center app, or by running `kinfo` in a terminal window)
Linux/KDE Plasma: Fedora 41, KDE edition
KDE Plasma Version: 6.2.4
KDE Frameworks Version: 6.9.0
Qt Version: 6.8.1

ADDITIONAL INFORMATION

Comment 1 scooter_icky238 2025-01-15 15:14:47 UTC

Is KWallet still maintained?

Comment 2 Nicolas Fella 2025-01-15 19:55:11 UTC

(In reply to scooter_icky238 from comment #1)
> Is KWallet still maintained?

yes

Comment 3 Nicolas Fella 2025-01-15 23:00:49 UTC

What seems to happen is that Chrome makes a DBus call to KWallet to open the wallet, see https://source.chromium.org/chromium/chromium/src/+/main:components/os_crypt/sync/kwallet_dbus.cc;l=165

The default timeout for a DBus call is 25 seconds, and Chrome uses the default timeout value. After that the Chrome window starts appearing. As far as I can tell the actual page loading still doesn't happen until I enter the wallet password and unlock the wallet, and after that the page with password loads fine.

The defaults 25 seconds being to short for the wallet unlock is a known thing, which is why when KDE applications use KWallet they increase the timeout, see https://invent.kde.org/frameworks/kwallet/-/blob/master/src/api/KWallet/kwallet.cpp#L260

However since Chrome does not use the KWallet C++ API but talks to it directly via DBus that doesn't apply to Chrome.

So no, the timeout is not an artificial, non-configurable delay implemented by KWallet, but rather the result of how the Chrome code is written. That means that any fix for this must happen in Chrome

Comment 4 scooter_icky238 2025-01-17 08:27:21 UTC

(In reply to Nicolas Fella from comment #3)
> What seems to happen is that Chrome makes a DBus call to KWallet to open the
> wallet, see
> https://source.chromium.org/chromium/chromium/src/+/main:components/os_crypt/
> sync/kwallet_dbus.cc;l=165
> 
> The default timeout for a DBus call is 25 seconds, and Chrome uses the
> default timeout value. After that the Chrome window starts appearing. As far
> as I can tell the actual page loading still doesn't happen until I enter the
> wallet password and unlock the wallet, and after that the page with password
> loads fine.
> 
> The defaults 25 seconds being to short for the wallet unlock is a known
> thing, which is why when KDE applications use KWallet they increase the
> timeout, see
> https://invent.kde.org/frameworks/kwallet/-/blob/master/src/api/KWallet/
> kwallet.cpp#L260
> 
> However since Chrome does not use the KWallet C++ API but talks to it
> directly via DBus that doesn't apply to Chrome.
> 
> So no, the timeout is not an artificial, non-configurable delay implemented
> by KWallet, but rather the result of how the Chrome code is written. That
> means that any fix for this must happen in Chrome

Thank you. I wonder what happens with gnome-keyring? I've seen it wait wait much more than a minute. 

Should this thread be closed?