SUMMARY KWallet Secret Service API does not persist new items to the wallet. If the daemon dies, the items are lost. STEPS TO REPRODUCE 1. Set up KWallet with Secret Service integration, install Seahorse and secret-tool. 2. Create a default wallet (I used a blowfish wallet). 3. Run `echo -n 'mypass' | secret-tool store --label=testfdo attr1 val1` in a terminal. 4. Inspect the wallet in KWalletManager and in Seahorse, run `secret-tool lookup attr1 val1`. 5. Restart `kwalletd5` (send signal USR1). 6. Unlock the wallet via Seahorse (see Bug 459287 why KWalletManager won't do here). 7. Repeat step 4. OBSERVED RESULT 4. The new item shows up (KWalletManager may need a restart to show it). 5. (The wallet is locked) 6. (The wallet is unlocked, KWalletManager may need a restart to show it.) 7. The new item is gone. EXPECTED RESULT 4. The new item shows up. 7. The new item is still there. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon User 20220825-0951 live DVD (after updating Qt libraries and KWallet) KDE Frameworks Version: 5.98.0 KWalletManager: 22.08.1 Seahorse: 3.36-1 libsecret: 0.20.4 libsecret-tools: 0.20.4 KDE Plasma Version: 5.25.4 Qt Version: 5.15.5 ADDITIONAL DETAILS Currently QtKeyChain still prefers the `org.kde.kwalletd5` API if it's available, so this is unlikely to affect most KDE apps just yet. But this needs to be addressed before the switch to Secret Service API is made.
Git commit abf970c067fa465ae9b7b970600de08f035d00e2 by Marco Martin, on behalf of David Edmundson. Committed on 11/04/2025 at 13:22. Pushed by mart into branch 'master'. Add secret service bridge The KWallet daemon is replaced by a new daemon which registers itself on the KWallet dbus service name and exposes all its old api. But instead of using directly the kwallet backend to store secrets, it proxies the api requests to a SecretService daemon, offering a compatibility layer for old kwallet-using applications. It is to be seen as legacy support and migration aid This daemon uses the same metadata format of QtKeychain, so when the application will migrate to it, a further data migration shouldn't be necessary The old KWalled daemon is still there: and is called KSecretd. It doesn't expose the kwallet dbus api animore, but only the SecretService api. It's used as the default secretservice provider for the new proxy kwalletd and it's launched by it unless is explicitly configured to not do so Related: bug 458644, bug 491280 M +12 -1 README.md M +5 -0 src/api/KWallet/org.kde.KWallet.nodeprecated.xml M +5 -0 src/api/KWallet/org.kde.KWallet.xml M +15 -0 src/runtime/ksecretd/CMakeLists.txt M +2 -0 src/runtime/ksecretd/kwalletfreedesktopcollection.cpp M +1 -0 src/runtime/ksecretd/kwalletfreedesktopservice.cpp M +1 -1 src/runtime/ksecretd/main.cpp A +3 -0 src/runtime/ksecretd/org.kde.secretservicecompat.service.in A +3 -0 src/runtime/ksecretd/org.kde.secretservicecompat.service.win.in A +73 -0 src/runtime/kwalletd/CMakeLists.txt A +1173 -0 src/runtime/kwalletd/kwalletd.cpp [License: LGPL(v2.0+)] A +216 -0 src/runtime/kwalletd/kwalletd.h [License: LGPL(v2.0+)] A +53 -0 src/runtime/kwalletd/main.cpp [License: GPL(3+eV) GPL(v3.0) LGPL(v2.0)] A +3 -0 src/runtime/kwalletd/org.kde.kwalletd5.service.in A +3 -0 src/runtime/kwalletd/org.kde.kwalletd5.service.win.in A +3 -0 src/runtime/kwalletd/org.kde.kwalletd6.service.in A +3 -0 src/runtime/kwalletd/org.kde.kwalletd6.service.win.in A +853 -0 src/runtime/kwalletd/secretserviceclient.cpp [License: LGPL(v2.0+)] A +108 -0 src/runtime/kwalletd/secretserviceclient.h [License: LGPL(v2.0+)] https://invent.kde.org/frameworks/kwallet/-/commit/abf970c067fa465ae9b7b970600de08f035d00e2