SUMMARY Storing a secret with `secret-tool` does not result in the entry being displayed by Wallet Manager, whereas other tools such as Seahorse do. STEPS TO REPRODUCE 1. run `secret-tool store --label='foo.bar' user me` 2. type secret 3. open Wallet Manager and search for 'foo' OBSERVED RESULT The secret is not listed or found. EXPECTED RESULT The secret is found and/or listed. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 42 KDE Plasma Version: 6.5.2 KDE Frameworks Version: 6.20.0 Qt Version: 6.9.3 Kernel Version: 6.17.8-200.fc42.x86_64 (64-bit) Graphics Platform: Wayland Processors: 14 × Intel® Core™ Ultra 5 125U Memory: 16 GiB of RAM (15.1 GiB usable) ADDITIONAL INFORMATION Seahorse lists a range of other secrets that Wallet Manager does not. It seems that whatever does not fall in the "Folders" scheme of KWallet is not displayed.
It expects the QtKeychain item schema. Everything else is ignored: > that is also expected, as kwalletmanager can understand only things that > have a particular schema, i don't think is much safe to do it differently > (like the magic attribute that has to be interpreted as folder) > so kwallet app will only get items of schema "org.qt.keychain" and the key > "server" will be interpreted as folder. I would definitely not make it a generic > secret service client, because the two things map only to a certain point. https://invent.kde.org/frameworks/kwallet/-/merge_requests/97#note_1232055
(In reply to michaelk83 from comment #1) > It expects the QtKeychain item schema. Everything else is ignored: > > > that is also expected, as kwalletmanager can understand only things that > > have a particular schema, i don't think is much safe to do it differently > > (like the magic attribute that has to be interpreted as folder) > > so kwallet app will only get items of schema "org.qt.keychain" and the key > > "server" will be interpreted as folder. I would definitely not make it a generic > > secret service client, because the two things map only to a certain point. > > https://invent.kde.org/frameworks/kwallet/-/merge_requests/97#note_1232055 Thank you. I had actually started reading that MR but did not go deep enough. (In reply to michaelk83 from comment #1) > It expects the QtKeychain item schema. Everything else is ignored: > > > that is also expected, as kwalletmanager can understand only things that > > have a particular schema, i don't think is much safe to do it differently > > (like the magic attribute that has to be interpreted as folder) > > so kwallet app will only get items of schema "org.qt.keychain" and the key > > "server" will be interpreted as folder. I would definitely not make it a generic > > secret service client, because the two things map only to a certain point. > > https://invent.kde.org/frameworks/kwallet/-/merge_requests/97#note_1232055 Thank you. I had started reading that MR but didn't get far enough to read that part :) While I understand the justification, I think the current status is unsatisfactory to some extent. Wallet Manager is the primary and only KDE application able to access the content of KWallet. Its GUI shows a "wallet" and a "Contents" pane. It is reasonable for a user to expect that "Content" shows all the content of the "wallet". Whereas this is not possible, Wallet Manager should warn the user that there may be hidden entries (with or without some way of detecting them). Can we turn this into a feature request, at least as long as KeepSecret (https://invent.kde.org/utilities/keepsecret) is not available?
(In reply to Massimiliano L from comment #2) > Wallet Manager is the primary and only KDE application able to access the > content of KWallet. Its GUI shows a "wallet" and a "Contents" pane. It is > reasonable for a user to expect that "Content" shows all the content of the > "wallet". If you're adding items via KWalletManager or via the KWallet API (client apps), they should all show up. If you're adding via Secret Service and adhere to the QtKeychain schema, then that's still compatible, and should work as well. Otherwise, you're essentially adding external items via an external system, that aren't part of KWallet. They just happen so reside in the same Secret Service collection. > Can we turn this into a feature request, at least as long as KeepSecret > (https://invent.kde.org/utilities/keepsecret) is not available? KWalletManager is severely outdated, suffering from many years of lack of developer resources. It's essintially end-of-life, just not officially declared as such. Current KWallet work is primarily focused on KeepSecret. Once it's ready, KWalletManager will very likely be dropped, and the legacy KWallet API will likely be deprecated (and eventually dropped as well; see bug 458318).
Meanwhile you can use: https://gitlab.com/GrantMoyer/lssecret There is an AUR if you are on Arch Linux: https://aur.archlinux.org/packages/lssecret-git From: https://askubuntu.com/a/1155765/517009 Usage: $ lssecret --help usage: lssecret [flags ...] -h, --help Print this message and exit. -s, --secrets Show secret values. Without this flag, all secret values will appear as '***'.