This universal password manager's backend in KWallet would be indeed very welcome!

I have to second that ...

*** This bug has been confirmed by popular vote. ***

What you want here is a separate daemon that exposes the pass backend through the Secret Service API. https://specifications.freedesktop.org/secret-service/latest/
But this will suffer from the same issue as Bug 458085, subject to the same fix in `gpg-agent.conf` (Bug 458085 comment 36 option A, or Bug 458085 comment 40).

If you're using another Secret Service provider such as Gnome keyring, KeePassXC, or KWallet itself (as of 5.97.0), you may as well just store your passwords there. It doesn't make sense to use both, IMO.

If a specific KDE app does not support Sercret Service yet, post a bug to that specific app to have it transition to QtKeyChain (or at least to libsecret, though QtKeyChain is preferred; they can both talk to Secret Service).

(In reply to michaelk83 from comment #4)
> What you want here is a separate daemon that exposes the pass backend
> through the Secret Service API.
Actually, this already exists: https://github.com/mdellweg/pass_secret_service
Should've googled first.

(In reply to michaelk83 from comment #5)
> (In reply to michaelk83 from comment #4)
> > What you want here is a separate daemon that exposes the pass backend
> > through the Secret Service API.
> Actually, this already exists:
> https://github.com/mdellweg/pass_secret_service
> Should've googled first.

I think we're talking about different things. As far as I understood that change from 5.97, it made passwords stored in kwallet accessible through the Secret Service API. What we want is the other way round, using passwords from other password stores in KDE apps. And that's still not possible. Please correct me if I'm wrong.

(In reply to Michi from comment #6)

The main goal of this task, as I understand, is to have KDE apps access passwords from the pass backend. The proposed solution was to integrate pass with KWallet, and then have the apps access KWallet. What I'm saying is that KDE apps can already access the pass backend via the Secret Service API, via e.g. https://github.com/mdellweg/pass_secret_service . They don't need KWallet as a middleman.

*Alternatively*, you can store all your passwords in any one of the other Secret Service backends, *without pass*, and have the apps access them there. KWallet can now also act as such a backend, as of 5.97.0. (It may eventually drop the old API, leaving only Secret Service - Bug 458318).

IOW, the apps would access all their passwords through Secret Service either way. You have a choice between different backends where to store the passwords: pass + pass_secret_service, KWallet, Gnome keyring, KeePassXC, etc. I don't see a reason to mix different backends.

I'm 110% in support of having KWallet be a front-end to a 'proper' OS password management service. Of the lot, I think Pass is the best candidate because of its near universal portability across *nix systems, its adherence to Unix philosophy, and brilliantly simple design.

However, as one of KDE's objectives is to be cross-platform, what considerations are there to hooking into other OS backends? Or is the intention for KWallet to be a *nix -only system?

For example, Mac OS stores passwords in Keychain. Although Mac ought to support Pass, Keychain might be a better backend for KWallet (although there's a good argument for segregating passwords from the Apple ecosystem). Likewise, Windows doesn't have a proper password manager, and my experience in using Pass on Windows is that it's very slow and cumbersome because it seems that GPG struggles with Windows.

Regardless, .kwallet files are too esoteric for a portable operating system, so turning KWallet into a front-end makes a lot more sense (and should save the devs some time if a proper API call can be developed).

(In reply to Borden from comment #8)
At least at the moment, KWallet and pass are two completely separate systems. They can each present the same Secret Service API to client apps, so the apps don't care which one is being used. (Pass needs some help for this from pass_secret_service or similar; KWallet needs at least version 5.97.0).

Pass has its own collection of front-ends. KWallet is not needed for this at all.

"KWallet" is actually two parts: KWallet daemon (aka KWallet Frameworks) is the backend, and KWalletManager is the front-end. KWalletManager can only talk to KWallet daemon. But with the new Secret Service support, you can replace KWalletManager with some other front-end such as Seahorse. (Technically, it was also possible with the old KWallet API, but I'm not aware of any other GUI front-ends to that API besides KWalletManager).

Regardless, KWallet (both parts of it) has been suffering from lack of developers for at least half a decade. AFAIK, it's an old, neglected piece of software, full of all sorts of problems. I expect that once the migration to Secret Service is more mature, KWallet will eventually be discontinued. KeePassXC is a popular alternative, but once again, it's not a front-end. KeePassXC is a complete package of its own, backend + front-end in one. But it is cross-platform, has many good features, and can present the same Secret Service API to client applications.

The direction for Linux is to have all client apps talk to Secret Service. Then you can switch in whatever backend you want for that, and write as many different front-ends as you want. They would all talk through the same API. But Secret Service itself is based on DBus, which is mostly Linux-only. If you want something really cross-platform, my recommendation goes back to the KeePass ecosystem.

(In reply to michaelk83 from comment #9)
Btw, if KDE devs decide to port KWalletManager to Secret Service before discontinuing it, *then* it can also act as a front-end for pass, again via the likes of pass_secret_service. Ultimately, it would be best to write a brand new client. Say, the KDE equivalent of Seahorse. But porting the existing KWalletManager is less work for now.

(In reply to michaelk83 from comment #9)
> Regardless, KWallet (both parts of it) has been suffering from lack of
> developers for at least half a decade. AFAIK, it's an old, neglected piece
> of software, full of all sorts of problems. I expect that once the migration
> to Secret Service is more mature, KWallet will eventually be discontinued.
> KeePassXC is a popular alternative, but once again, it's not a front-end.
> KeePassXC is a complete package of its own, backend + front-end in one. But
> it is cross-platform, has many good features, and can present the same
> Secret Service API to client applications.
> 

True, but KeePass (not sure if with or without XC) can also kind of act as a backend. e.g. for Gnome, there is a gtk UI available that is based on KeePass.
Similarly, it might be possible to provide something that is based on KeePass, but integrates better with KDE. Given that KeePassXC is already using Qt for its UI, it might actually be easier than the Gnome part that is out there.
It would certainly help if KDE's password manager would use a file format that is better exchangeable with other tools. Right now, if you're using kwallet, you're more or less stuck with it (and thus with a broken tool) unless you're willing to do a full manual migration to some other tool.

(In reply to Bernd Steinhauser from comment #11)
> It would certainly help if KDE's password manager would use a file format
> that is better exchangeable with other tools. Right now, if you're using
> kwallet, you're more or less stuck with it (and thus with a broken tool)
> unless you're willing to do a full manual migration to some other tool.

Agreed. The moral of the story is that it's time for the .kwl file format to go peacefully into the night and make way for formats that are widely used.

(In reply to Bernd Steinhauser from comment #11)
For KeePass, there is a standard file format (`.kdbx`) that multiple applications can work with, and indeed there are many KeePass variations that all work with this format, some platform-specific like Keepass2Android, others more cross-platform, like KeePassXC. Of those, KeePassXC can also act as a Secret Service backend. But it comes with its own UI, which while it is Qt, is not fully integrated with KDE, and will likely stay that way. There is some work there to separate its core from its GUI, so eventually it might provide Secret Service headless. Or someone could implement a separate Secret Service backend that could work with `.kdbx` files.

Gnome has a password manager that works with `.kdbx` but AFAIK doesn't provide Sercret Service, and it has Gnome keyring that provides Secret Service, but doesn't work with `.kdbx`. There's also Seahorse, which is a general front-end for Sercret Service, but not sure how well-integrated it is with the DE.

Eventually Linux should get native Secret Service front-ends with proper DE integration. Then you can pick and choose which backend you want to use with that, and correspondingly, which file format you want to work with, whether it's `.kwl`, or `.kdbx`, or `pass`, or whichever else. `.kdbx` is the most cross-platform, I think.

For `kdbx` support, see also Bug 455041.

(In reply to michaelk83 from comment #13)
> (In reply to Bernd Steinhauser from comment #11)
> For KeePass, there is a standard file format (`.kdbx`) that multiple
> applications can work with, and indeed there are many KeePass variations
> that all work with this format, some platform-specific like Keepass2Android,
> others more cross-platform, like KeePassXC. Of those, KeePassXC can also act
> as a Secret Service backend. But it comes with its own UI, which while it is
> Qt, is not fully integrated with KDE, and will likely stay that way. There
> is some work there to separate its core from its GUI, so eventually it might
> provide Secret Service headless. Or someone could implement a separate
> Secret Service backend that could work with `.kdbx` files.
> 
Well, yes, KeePassXC will surely want to stay independent and that's alright. What I wanted to say is that it might be easier to use that as a starting point and then modify parts of it to integrate better with KDE instead of writing a completely new thing that supports kdbx.
Especially, since I would also want other features from KeePassXC as well, like the password generator, restricting app access to certain groups etc.