There is more thorough description in this bugzilla report:
https://bugs.kde.org/show_bug.cgi?id=498695
But the TL;DR is that when an application requests access to the wallet through the Secret Service API, it expects you to enter the password very quickly. If you do not, it will provide the application with an error (and leave you with whatever error handling mechanism the said application has), while keeping the password dialogue open. In case of Chromium this means losing access to your cookies and sessions.
My questions are:
- Does anyone else experience this?
- Is KWallet even maintained?
Hi! I’m far from an expert on the topic and don’t experience it myself - my wallet is set to unlock when I login - but it does sound like there are some similar instances of folks finding that applications calling for authorization are themselves timing out while waiting for it:
The comments on that last one would make me suspect that it has something to do with how the source application is making the “call” to the Secret Service / KWallet (allowing a default D-Bus 25 second timeout, maybe?), but that would be a total guess.
As a general workaround, is it an option for you to have your wallet unlock when you login?
Related to the question of whether KWallet is maintained, since it’s open-source and community-developed out in the open, you can look at things like the commit or merge request history to see if activity is still happening on a particular project: Merge requests · Frameworks / KWallet Framework · GitLab
In my non-developer opinion, the most exciting current work is happening under Draft: Transitional system for KWallet to SecretService (!97) · Merge requests · Frameworks / KWallet Framework · GitLab , to work toward a state in which KDE applications can interact with password storage nicely on all platforms, non-KDE applications can store passwords correctly on Plasma, and as much happens without requiring user interaction as possible.
@Delusionalpeter:
Also– Hi! And, welcome to the KDE Discuss Forum.
I also unlock KWallet at login – the details are well documented here – <ArchWiki: KDE Wallet>
One thing to watch out for is, the Preference setting “Close when unused for:” documented here: <KDE: Configuring KWallet>
And yes, anything which doesn’t cache it’s KWallet items at login – such as the Google/Alphabet Chromium browser – will have problems and issues if and when the Wallet closes …
1 Like
Thank you, but I’m afraid that’s not the problem I’m encountering.
I don’t unlock KWallet at login, it has a different password from my user password.
The problem is KWallet timeout-ing the password dialogue and leaving the application requesting access with an error that I think is not typical, because Gnome Keyring doesn’t do it.
Thanks, I wonder why I couldn’t find those with google…
However it looks like all of them were unsolved except for the github issue and that I commented on right before the contributor stated it’s fixed.