Bug 498695 - KWallet unlock dialogue timeouts when invoked through the Secret Service DBUS interface
Summary: KWallet unlock dialogue timeouts when invoked through the Secret Service DBUS...
Status: RESOLVED DOWNSTREAM
Alias: None
Product: frameworks-kwallet
Classification: Frameworks and Libraries
Component: general (other bugs)
Version First Reported In: 6.9.0
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Valentin Rusu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-01-15 15:12 UTC by scooter_icky238
Modified: 2025-01-17 08:27 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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?