Make KPXC databases accessible via libsecret/DBus [$175 awarded]

[lofidevops]

User story: I am a GNU/Linux desktop user with a standard (libsecret-based) password manager. [1] I want to use the same password manager to access my KPXC databases.

[1] For example using GNOME Passwords and Keys UI (aka Seahorse) to access GNOME Keyring daemon.

Possible Solution

• Make a libsecret-KPXC interface
• Test that it accessible from GNOME Keyring (for example)

[eNTi]

uhm... are you sure this is the correct example?

[lofidevops]

It's what I'm thinking of. If you can provide better or alternate examples, or if I've been unclear, please suggest them and I'll modify the description.

[eppelmania]

I think one intention of issue #440 was to use KPXC as system keyring. So there would be no more need for seahorse or kwallet.

The user story would be more like the following:
I am a GNU/Linux desktop user and I want to use keepassxc instead of seahorse/kwallet.

[kabili207]

Seahorse and kwallet are user interfaces that interact with a libsecret keyring, they are not the actual keyring. The actual underlying keyring implementations are called gnome-keyring and ksecretservice.

This user story is about replacing the underlying implementations. Anything that would normally use gnome-keyring, such as seahorse or chrome or whatever, will talk to keepassxc instead.

[eppelmania]

Ok. So the possible solution would be. Make a libsecret-KPXC interface und test if it is accessible from seahorse, chrome, etc.

But shouldn't there also be some session handling stuff involved, for example automatic unlocking of the database after login, or is this already part of the libsecret interface.

[kabili207]

Libscret does include stuff in the API that signals the keyring to open a "master password" entry screen among other things, but I think that a libsecret-kpxc daemon would need to be running in the background for any of the API to even work.

[kakra]

@kabili207 As far as I understood, the secret service API is dbus activated. So "the daemon" is already there and could start keepass on demand.

[kabili207]

@kakra You're probably right. It's been quite some time since I've looked into the secret service API.

[mjsir911]

Would this launch as a very minimal application just acting as a daemon to serve as a libsecret password server or would the secret service API start up the entire KPXC program, GUI and all?

[kakra]

I guess it should have two modes: Either you start keepassx GUI and that provides the interface, or it is launched if you enable the autostart on activation service. Personally, I probably don't care if it starts the full GUI or just a one-shot minimal service. As long as the interface is already provided, it won't fire something up at all. At least this is how I guess it could work. It's probably more complicated in the background, I'm no dbus programmer.

[guillaume-uH57J9]

To be useful (ie and make the database accessible), I'm guessing keepassxc needs to be unlocked first, trough its GUI.

So I don't the advantage in adding a service here. A service without GUI might be able to start earlier in the boot process (in the case of a system service) or earlier in the user session (in the case of a user daemon). But I see no point in doing that, even if the service can be started earlier than the GUI, it won't be able to serve requests until the GUI is started and the database unlocked.

Edit : note I'm not a keepassxc developer, so I might be wrong.
I am basically suggesting it might not be worth adding a service, unless someone can show there a need for one.

[kakra]

Well, I wrote "one-shot minimal service" because I've thought of something that just asks for the unlock password, provides access, and then exits again. As it doesn't have the full-blown feature set (password generator, editing), it should be able to load fast and use less memory.

But memory is cheap these days, I don't really get the point why such an activation request shouldn't pull up the complete GUI daemon. I was just giving an example of a possible solution for people concerned for whatever reason with running the GUI process all the time. Personally, resource usage should not be a concern, especially thinking of opening and closing the databases and spawning processes every time an activation is made could be much more expensive.

If dbus activation works well enough, keepassxc could implement an option to completely shut the GUI down after a certain timeout (like 10 minutes or whatever feels right).

[guillaume-uH57J9]

That's a good point, sorry for missing your point on this service being one-shot and D-Bus activated.

Not sure if keepassxc would be memory hungry.

Measuring memory usage is not obvious. I ran a quick test wish massif which shows heap memory usage (malloc/new/...) is around 13.6M which sounds reasonable.
However htop report a much higher memory usage of 832M, presumably because of shared libraries takes a lot of space. So it depends if you want to consider shared memory here.

I'd already be very happy if keepassxc was available through libsecret/DBus, and would argue adding the option to have a one-short service is secondary.

[phoerious]

832MB is probably virtual memory, not actually consumed memory.

[kakra]

You should use a memory monitor that gives you proportional memory usage (I think that would be PRSS or PSS = proportional [resident] set size), that's it calculates shared memory in relation to other processes' shared memory, giving a more accurate idea of effective memory usage (it's still wrong tho because you cannot exactly account shared memory to one or another process).

https://en.wikipedia.org/wiki/Proportional_set_size

[mjsir911]

I'm not very well-versed with the KeepassXC codebase, but I am trying to keep extra dependencies needed for this issue at a minimum.

Does KeepassXC have everything needed for this algorithm(s?).
Just from a quick look I can't find that it uses a library that supports DH, aka Diffie-Hellman

And if I am forced to add an additional dependency, is that alright, any preferences for crypto libraries? I've very slightly dabbled with crypto++ and that seems to do what I need.

[droidmonkey]

Libsodium, already a dependency, probably has what you need.

https://download.libsodium.org/doc/advanced/scalar_multiplication.html

[Grief]

I am not sure, but I assume that kwallet (KDE) and gnome-keyring (Gnome) have significant differences, otherwise there won't be tons of unanswered questions (like this one) about how to replace one with another in the internet.

[intika]

@Grief nope it's just kind a lot of work to implement dbus and replace kde/gnome keyring ... it's just not available right now until a dev would need the feature lol

[hrehfeld]

What's the status on this?

I can add the following user stories:

• I need to access my keepass data from offlineimap (python) via the python keyring library without additional password prompts

[virtualdxs]

Is there a bounty program set up for this? I'd be willing to contribute money to get this done.

[droidmonkey]

I have considered starting a bounty run for KeePassXC. I looked into a couple services, they all looked a tad sketchy. Do you have a suggestion?

[virtualdxs]

https://www.bountysource.com/ is the one I've seen repeatedly

[virtualdxs]

I just want to verify - this will include having a systemd user service that implements/provides org.freedesktop.secrets, correct? My main use case of this issue is for Nextcloud client credential storage.

[nazar-pc]

Yes, Nextcloud and I believe IntelliJ IDEA uses it as well, I'd be happy to remove Gnome's implementation from my system entirely.

[affinityv]

Please limit any requirements to require dbus and systemd -- they should be optional only as there are alternatives and a great number of people whom understand that systemd is a cancer on Linux.

[Skycoder42]

The dbus requirement is fixed, as the secret service API is a dbus service. But I do agree that there should be no hard requirements on systemd. Instead, creating a seperated excutable that provides the dbus service would make it easily possible to run it as systemd service - and ideally such a service file would be provided as part of keepassxc

[virtualdxs]

@affinityv I agree that there should not be a dependency on systemd. That being said, it's inappropriate to call systemd a "cancer", as it's both an inaccurate analogy and disrespectful to those who have lost someone to cancer.

[MurzNN]

For make KPXC available via DBus we can implement, at first step, access to passwords via dbus commands, like KWallet do now:

method QByteArray org.kde.KWallet.readEntry(int handle, QString folder, QString key, QString appid)
method QVariantMap org.kde.KWallet.readEntryList(int handle, QString folder, QString key, QString appid)
method QByteArray org.kde.KWallet.readMap(int handle, QString folder, QString key, QString appid)
method QVariantMap org.kde.KWallet.readMapList(int handle, QString folder, QString key, QString appid)
method QString org.kde.KWallet.readPassword(int handle, QString folder, QString key, QString appid)
method QVariantMap org.kde.KWallet.readPasswordList(int handle, QString folder, QString key, QString appid)
method int org.kde.KWallet.removeEntry(int handle, QString folder, QString key, QString appid)
method bool org.kde.KWallet.removeFolder(int handle, QString folder, QString appid)
method int org.kde.KWallet.renameEntry(int handle, QString folder, QString oldName, QString newName, QString appid)
method int org.kde.KWallet.writeEntry(int handle, QString folder, QString key, QByteArray value, QString appid)
method int org.kde.KWallet.writeEntry(int handle, QString folder, QString key, QByteArray value, int entryType, QString appid)
method int org.kde.KWallet.writeMap(int handle, QString folder, QString key, QByteArray value, QString appid)
method int org.kde.KWallet.writePassword(int handle, QString folder, QString key, QString value, QString appid)

[ntninja]

@virtualdxs: systemd is only relevant insofar as that you can have D-Bus autostart service (autoactivation) on first access and that autoactivation can defer to a systemd service. I wasn't really planning on providing the relevant activation files, but writing (read: copying an existing and adapting) one is trivial and if people want this I see no reason why it shouldn't work.

@MurzNN: This proposal is specifically about implementing a SecretService-compatible service. Exposing KWallet or a custom API is not planned at this time. However exposing KWallet once SecretService is in place will be able to reuse most code and hence will only require modest extra effort.
As for exposing a custom API: Honestly I don't see any good reason why “native client” should use D-Bus rather then just connecting to the relevant Unix socket directly. Just for the sake of completeness maybe? Also please don't take any inspiration from KWallet however: Their API is the worst in a lot of ways (cleartext passwords, useless client isolation) and a new protocol should definitely not attempt to replicate this.

[virtualdxs]

@Alexander255 Just to clarify, I'm specifically referring to the message ** Message: 22:22:32.970: Remote error from secret service: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files. If that's just about activation, then that's perfect. I'm very familiar with the systemd unit file syntax.

[ntninja]

@virtualdxs: That message just is D-Bus daemon saying: Nobody provides the SecretService API and I can't figure out how to fix it. If you'd start an application providing the API manually the message would go away as well – activation is only attempted since the API wasn't provided by anybody, it then fails however causing the error message you observe.

[hrehfeld]

Awesome! 👍

[droidmonkey]

It will be in the 2.5.0 release. If you want to try it out now you can use our snapshot builds: https://snapshot.keepassxc.org

[guillaume-uH57J9]

Thanks for doing this. I'm too late to chip in for the bounty, so I setup a recurring contribution using liberapay