SUMMARY (I think this problem is related to Bug #400462 "kwalletd legacy dbus service file". I'm not entirely sure if it's actually a KDE bug or a packaging bug in KDE Neon.) STEPS TO REPRODUCE 1. Upgrade to KDE Wallet from Frameworks 5.61.0. 2. Perform "qdbus org.kde.kwalletd" OBSERVED RESULT qdbus will complain that the service could not be found (unfortunately I was stupid enough not to make a copy of the acutal error message before downgrading KDE Wallet again, sorry. :-( ) EXPECTED RESULT As in KWallet from Frameworks 5.60.x: $ qdbus org.kde.kwalletd / /MainApplication /modules /modules/kwalletd /modules/kwalletd5 /org /org/kde /org/kde/kwalletd5 SOFTWARE/OS VERSIONS KDE Neon KDE Plasma: 5.16.4 KDE Frameworks 5.61.0 Qt 5.12.3 (kompiliert gegen 5.12.3) Das xcb Fenstersystem KDE Applications: 19.08.0 ADDITIONAL INFORMATION Yesterday's KDE Frameworks update broke Chromium's Wallet integration, access to all stored passwords was immediately lost. Apparently, Chromium tries to contact Wallet using the dbus service name org.kde.kwalletd which worked flawless up to and including KDE Frameworks 5.60. In Frameworks 5.61 Bug #400462 was implemented which states a question about a malformed service file in Frameworks up to version 5.60, but which also explicitly states that the service file should just be fixed such that the "org.kde.kwalletd" service name is provided properly. (Please read the original request in #400462.) Unfortunately, at least in the KDE Neon packaging of Frameworks 5.61, the service file providing org.kde.kwalletd is removed entirely, breaking existing applications without any prior notice! I tried to recreate / restore the org.kde.kwalletd.service file, but to no avail - the dbus service was available again afterwards, but seemed to look differently than in Frameworks 5.60 and Chromium still wasn't able to access its stored passwords. So I manually pinned the KDE Wallet packages to version 5.60.0 in APT preferences and downgraded just KDE Wallet. Afterwards, Chromium worked fine again after a logout and re-login. If this was an intended breakage to remove old compatibility cruft, there should have been a *really* *big* *warning* in the KF 5.61 release notes! Your users may lose access to important credentials simply by upgrading, and depending on their tech saviness, they may lose it permanently! A backup of your home directory will not help in this case, you'd need to restore your whole system from a backup if you don't know how to downgrade KF or at least KDE Wallet manually. (And before I did I even wasn't sure if it would work at all.) If this was not an intended breakage, the problem should be fixed really soon from my point of view. If it's a packaging issue in KDE Neon, it should quickly be fixed there, before too many users get bitten badly... :-/
Are there already any plans if - and if yes, when - this might be resolved? If it's not planned to be resolved, what are the recommended workaround?
chromium works fine with kwallet 5.61. Are you perhaps calling it with "--password-store=kwallet"
(In reply to Antonio Rojas from comment #2) > chromium works fine with kwallet 5.61. Are you perhaps calling it with > "--password-store=kwallet" Yes. How else can I make it work together with KDE Wallet from KF 5? Do you have any background documentation for me to get better insight into the big picture? I thought that without any argument, Chromium will default to it's unencrypted built-in passwort store. And besides this, a big warning before removing this functionality / changing it in an incompatible way would have been important, as you immediately lose access to all stored passwords once you upgrade...
(In reply to Gunter Ohrner from comment #3) > (In reply to Antonio Rojas from comment #2) > > chromium works fine with kwallet 5.61. Are you perhaps calling it with > > "--password-store=kwallet" > > Yes. How else can I make it work together with KDE Wallet from KF 5? That's the problem then, you are explicitely asking it to use the deprecated kde4 interface. Use kwallet5 for the KF5 one. This is indeed quite poorly documented. https://chromium.googlesource.com/chromium/src/+/8917b83c677a8c632d5df666f72046f80c74472d
(In reply to Antonio Rojas from comment #4) > That's the problem then, you are explicitely asking it to use the deprecated > kde4 interface. Use kwallet5 for the KF5 one. This is indeed quite poorly > documented. Thanks, this actually seems to work (even though I'm currently still on the old kwalletd, so I'll have to properly check this after upgrading again.) "Poorly documented" is some kind of understandment here, though - Chromium does not even list kwallet5 as a possible value for this option in it's command line help: --password-store=<basic|gnome|kwallet> Set the password store to use. The default is to automatically detect based on the desktop environment. basic selects the built in, unencrypted password store. gnome selects Gnome keyring. kwallet selects (KDE) KWallet. (Note that KWallet may not work reliably outside KDE.)
I reported this issue in the Chromium bug tracker: * https://bugs.chromium.org/p/chromium/issues/detail?id=1004785 The behaviour is even more annoying, as there does not seem to be a way to permanently select the default password store. As the Chromium command line help I quoted says, "The default is to automatically detect based on the desktop environment." And apparently, in KDE, also in KDE 5, and also with KF 5.61 and later, always "kwallet" seems to be chosen as the password store, never "kwallet5". This means, I cannot easily start Chromium via the desktop any more, but have to resort to the command line. (I could probably add a one-line shell script or adjust the *.desktop file for Chromium to start it with the right command line arguments, but that's not something I'd normally expect a user to have to do...)