SUMMARY This isn't necessarily a bug with Kwallet but rather a usability gripe with it about how it's designed as a whole. Comparing Kwallet to the likes of KeePassXC, Kwallet's password management is less structured to maintained in the UI and has far fewer features than KeePassXC. Some will say: "then don't use Kwallet," but there's a few problems with this that I'm going to get into but my primary response to this is that I don't *mind* Kwallet as a concept but I find it greatly lacking and even frustrating in a few different ways. One of these reasons is because of the aforementioned lack of features compared to KeePassXC: as it stands, KeePassXC is superior to Kwallet almost in every conceivable way. So much so, that I honestly think KDE should actually integrate KeePassXC better into Plasma and SystemSettings officially *instead* of Kwallet because of both how much better it manages data (from the user-end) and its other great features like: password generation, 2FA/OTP, and browser integration. As a user, I interact far more with KeePassXC as a password manager than with Kwallet and this brings us to my next point... In my experience, Kwallet does a better job at requesting for authentication for desktop applications than KeePassXC; kwalletd5 is just better than the KeePassXC secrets integration and matches the system theme better; however, Kwallet has an irritating user flaw: if a user opts to save a credential but enters it incorrectly (to my recollection or something to that effect), fixing this becomes an unnecessarily frustrating task to fix. An example would be like using git@github SSH and then being stuck having to enter the key manually forever because Kwallet won't prompt for this anymore. Another usability example would be when a matrix client asks to save encryption key data to Kwallet but Kwallet's only export options are XML and "encrypted;" which on its own isn't "bad," but when KeePassXC is so much more feature-complete than Kwallet, makes transferring this data either impossible or non-user friendly enough to seem that way thereby barring user-choice and unintentionally creating a "lock-in" if they discover KeePassXC later because Kwallet is the KDE community default. That said, I think it would be better for the Plasma ecosystem as a whole to adopt a fork of KeePassXC to integrate with kwalletd5 to get the best of authentication requests, user data management, and user security in regards to supporting secure password generation, and 2FA/OTP. Another option is to evolve Kwallet far beyond what it is in both UX/UI and usability but... honestly, that would be far more work than just implementing a rebranded KeePassXC fork because it functions and already feels like it belongs in a Plasma desktop; Kwallet seems almost ancient by comparison, in my opinion. OBSERVED RESULT Kwallet, despite being an official KDE password manager, falls short in how effective it should be. EXPECTED RESULT Kwallet should either officially integrate with a fork of a superior Qt offering or substantially adapt to achieving equal parity in design and functionality. SOFTWARE/OS VERSIONS Linux: Arch Linux x86_64 KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 ADDITIONAL INFORMATION N/A
For clarification, for anyone potentially investigating this, KeePassXC does support native themeing like Plasma does as an optional setting (though this isn't the default behavior).
AFAIK, KWallet has suffered from a shortage of developer time for many years. It is indeed outdated, and not likely to be vastly improved any time soon. The overall direction for Linux is to switch to Sercret Service, and kwalletd5 has very recently received its own Secret Service API support. This now creates a common interface between the different secret storage backends, client applications, and manager applicatons, so different backends become interchangeable, and different managers become interchangeable. Instead of a manager specific to kwalletd5, you would have a manager for Sercet Service, and it would be able to talk to any of the Sercret Service backends. Right now, there is Gnome's Seahorse, which can now talk to kwalletd5 as well. There's no KDE-native equivalent yet, that I'm aware of. But there is now both the ability and justification to develop one. (There is also KeePassXC's own UI, but that can only talk to KeePassXC.) As the migration to Secret Service matures, eventually, the old KWallet API can be deprecated (Bug 458318), and at that point, either KWalletManager will need to be ported to Secret Service as well, or it will need to be replaced by a new Secret Service manager. I agree that an official KDE fork of KeePassXC is also an interesting idea. In the mean time, if you encounter a KDE app that doesn't support Secret Service yet, encourage its maintainers to switch to QtKeyChain, or at least to libsecert. The former is preferred. It supports both Secret Service and the old KWallet API. As for your concerns with KeePassXC, you can try raising those with KeePassXC's developers (but do search for existing issues first).
There seems to be a three year-old existing issue about supporting Kwallet over there, so I referenced this issue and that suggestion you mentioned: https://github.com/keepassxreboot/keepassxc/issues/3679
Lmao As soon as I mentioned what I suggested here about a KDE KeePassXC, I already got a negative reaction from one of their devs: https://github.com/keepassxreboot/keepassxc/issues/3679#issuecomment-1246043235
(In reply to michaelk83 from comment #2) > As for your concerns with KeePassXC, you can try raising those with > KeePassXC's developers (but do search for existing issues first). What I meant was if you have some specific improvements in mind, such as for the authentication prompts: > Kwallet does a better job at requesting for authentication for desktop applications than KeePassXC; > kwalletd5 is just better than the KeePassXC secrets integration and matches the system theme better; Note though that KWallet actually does a very poor job at asking for authentication, since it has no code to identify which app is trying to access KWallet (Bug 451039). KeePassXC is much better on that front. Also, if you're using a GPG wallet, the passphrase request isn't even done by KWallet at all - it's done by GPG.