KeepSecret is our new password management application, based on SecretService, which works both with our old KWallet infrastructure as well as more modern services such as oo7, KeepassXC and many others.
I want to like it, but its interface requires > 5 Ă— the amount of space that its predecessor does:
What’s wrong with a QTreeWidget…?
Additionally, it animates its About and Help pages, despite animations being disabled system-wide for me, which isn’t great for accessibility and performance. I’d report it, but every new KDE application suffers from this, and I can’t spend my life reporting it.
This seems to be a Kirigami framework bug. But I can’t be sure, so just report it for one of the applications ( something frequently updated for visibility ) , the triagers will move it to the appropriate framework if needed.
This is the kind of accessibility issue that get fixed relatively fast ( Ofc. can’t speak for this particular case - just going by the general feel ), so it getting passed on because no one has reported it would be shame.
The reduced information density is a bit off, I agree. I’ve submitted a merge request to increase it: Increase main list view information density (!28) · Merge requests · Utilities / KeepSecret · GitLab
The page animations not respecting the animation duration is a bug. Seems a bit subtle as I haven’t figured it out yet. There’s a bug report: https://bugs.kde.org/show_bug.cgi?id=445630
QTreeWidget’s problem is that is implements a tree view. Normal people (not you and me) have trouble with tree views. See Trees, TreeViews, and UI
How to set this up to work with the “kdewallet” created with KWallet Manager?
Installed keepsecret 1.0 on Arch and now it is at version 1.1 but I (still) only get a “The name is not activatable” on a mostly empty window.
Well there is “Delete Wallet” and “+ New Wallet” but as it claims to work “with” KWallet, and all the others, I am not sure if I want to do any of those two things and accidentality delete and or overwrite my old wallet with a empty one. As there is no archwiki entry (yet) nor the blogposts about it, at least the blogposts I found, explain things.
Works for me on KDE Linux. Maybe you don’t have SecretService or KWallet installed or enabled?
While KeePassXC for my (Firefox) Browser Webpage logins is probably not part of SecretService (or KWallet) I have used KWalletManager to set up “kdewallet” and stored my home Wifi password there.
Would KWalletManager even work without KWallet installed or disabled?
There can only be one secret service active at a time as they have to open up the appropriate socket uniquely, if you stop the old kwalletd, it’ll probably start.
I am a bit curious your plans for this long-term. I’d started working on a general purpose mcp server, I needed a way to feed secrets into it, and began trying to use the local linux secrets, but really found it too limiting (no concept of username, only relative to the user). Kwallet didn’t seem to really offer any more.
I moved recently to using keepassxc as the secret provider hoping to get some categorical hierarchy to password management, but sadly doesn’t really improve on secrets in any way, only exposes a single, flat directory of credentials of choice. Even its own CLI is useless if using MFA like a yubikey, and their browser plugin is limited to only searching credentials by URL’s, that isn’t always useful for non-url credentials. There is no real wholesale api otherwise.
Really I need a local means of exposing/enumerating a full credential management database, including ssh keys/certs, x509 pub/priv keys, username/password, totp, etc. Sadly secrets will probably remain just what it is forever to keep the peace, but wondering if any plans to provide an alternative api for accessing credentials here?
Keepassxc would be great if it weren’t for the fact it really has no way to search by key values, for fear of being exploited. By nature I suppose this is prudent, but seeing most cloud-based keyvaults offer this now with various mitigating controls, seems just being obstinate now.
I used Lasspass until they got uberhacked circa 2018, and was almost considering Bitwarden until supply chain attacks against their cli that I probably would have been using recently, so more than ever I’m keen to keep my secrets out of any cloud. It would be nice to get a properly extensible secrets api out of something, and not really found anything that I was even considering forking keepassxc.
@ngraham, considering that the hierarchical indentation remains in those screenshots, and any indentation below one level of depth has been replaced with a (less readable) path separator, haven’t we merely reinvented the tree widget, but worse? It doesn’t ecen utilise indentation lines, nor are the icons aligned.
I realise that QML lacked a tree widget for a long time, but it should have one nowadays.
Other than when we work together on the CommonMark Discourse instance, I somehow always end-up disagreeing with him, on everything, although I’m not alone:
@Jack_White, the problem is how inconsistent it is:
I’d err on it somehow being an implementation defect within the application.
@mikus, if your project is hosted on a forge that provides a public issue tracker, I recommend that you file an issue about this, and link to it. That’s a problem worth solving, and might require evaluation of many solutions. In the meantime, you may want to check:
You’re looking at a one-dimensional flat list view. That’s what it is. It’s not a tree view.
If you think tree views are better, that means you’re in a very special group of people (I’m in it too!) whose brains are capable of appreciating tree views.
Most people aren’t like us.
Nowadays KDE software is designed to be usable by normal people, not just programmers and nerds. We don’t always hit the mark, but that’s what we’re aiming for. Hence, minimizing tree views and similar complex controls that don’t text well, in general.
I don’t make my mcp public yet as it’s sort of a perpetual state of flux still though I use it every day, but generally I plan to when I can consider it more than a vibe-coded experiment.
In it I built out a linux secrets integration that I mostly use now since keepassxc proved a bit fruitless, and planned to look at bitwarden, but having their supply chain compromised for their cli component with malware doesn’t instill much future confidence in them when my whole use case is around their cli/api. Then again not their fault npm, pypi, and others are such a mess now that they are targets.
When I looked 6mo or so ago bitwarden didn’t support local dbus gnome-keyring-style secrets which was annoying, though it supported the api-side better, but for me only half of a solution. Then again, the old linux secrets is pretty simple/dumb, and doesn’t really fit a more than a simple password storage model (i.e. no username, no alternate fields, no ssh key/cert, no pki).
Keepassxc would be ideal with a proper searchable api and a nice gui, but the author seems to want to die on the hill to prevent features to make it more extensible for fear of “dumping” attacks, even after numerous feature requests for it, probably driving folks away. API-based secret managers do allow more flexible searching, but use some sort of time-based (re)validation as a mitigating control. All seem to introduce somewhat necessary friction, none complete for fear of being too good for crims with bad intentions to access and jackpot your trove.
General research indicated I probably need to look at something more commercial for secrets. I actually built stubs for hashicorp vault, akeyless, aws secrets, azure keyvault, and keeper as sort of a stretch to support as many as I get around to testing (various customers of mine use a variety of these). I just don’t see myself using these for personal things, only customer integrations when needed.
Hopefully this gives some ideas as food for thought around secrets. I was interested for a new KDE password manager when announced, but I need less simple, not more.
@ngraham, thanks.
I might be misattributing the lack of icons for the non-heading sections to be indentation, then. Otherwise, we might differ in what we refer to as a mere list.
@mikus, I cited it as a development reference, rather than a solution.
We do indeed. I’m referring to it as a list because it’s a list, while you appear to be attempting to redefine it as a type of tree view, I think because it has section headers with icons and the list items are visually indented.
These are visual design choices. They don’t mean it’s a tree view.
I’m afraid you need to do what browsers do: create your own secret storage, encrypt the whole database with a master key, then store the key in the system secret provider.
There is a kwalletd6 running, but no easy (with the emphasis on “easy” for the user e.g. me 
) way to stop that as nothing with “wallet” is listed as a systemctl manageable service/unit.
The Archwiki mentions it would be activated through /etc/pam.d/sddm (as I still use sddm) but that removing those lines would just result in a fall back to the KDE 5 kwallet (? not tried).
Unchecking “use KDE-Wallet subsystem” in the KDE settings does stop kwalletd6 but while KwalletManager stops working I get the same message from KeepSecret.
I probably wait until KDE switches completely over to KeepSecret and removes KwalletManager, for (my own) convenience (and run into a complete unsolvable disaster when that happens 
).
Thanks.
Edit: Some progress:
After creating a “Automatic D-Bus activation” file which did not exist at all, more precisely
~/.local/share/dbus-1/services/org.freedesktop.secrets.service containing:
[D-BUS Service]
Name=org.freedesktop.secrets
Exec=/usr/bin/kwalletd6
The “The name is not activatable” error message is gone.
Still completely empty as the “kdewallet” wallet does not show up, though.
Edit2: (had to wait some time for the next error message 
)
Now i run into a (roughly translated) “Error calling StartServiceByName for org.freedesktop.secrets: Timeout reached”.
I used to use LastPass until their disclosure snafu a few years ago, when I moved to Bitwarden on my desktop, phone and tablet. The supply-chain attack you mention was closed within 90 minutes and (as you say) only affected the CLI, which I don’t use. The problem with keeping everything off the cloud is that you get to manage your password database across devices by yourself, which in 99% of cases leads to worse security. You do you but I don’t see myself changing.
I think there is: Credentials for Linux