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

[intika]

Or simpler an issue with a Paypal account/link

[virtualdxs]

That's less transparent and has less accountability. I wouldn't donate through that.

[ntninja]

Well, here we go: https://www.bountysource.com/issues/53971701-make-kpxc-databases-accessible-via-libsecret-dbus

I, as a developer of other stuff not KeePass*, just spent a little bit of time looking into this. Some observations:

1. Implementing the Secret Service D-Bus API isn't that hard, but likely somewhat time intensive:
   • The bus level crypto (for transferring secrets) is optional, so one can start without this for testing and tackle it later on when everything else works – a proper implementation will need this through!

2. It isn't immediately obvious how to map the API's support for “non-default collections”: In theory they'd be a perfect match for accessing different .kdbx database files over the bus, but how would one know which .kdbx file matches which collection alias names?

   • In practice this likely requires some kind of management application to be written which will ask users where new collections should be stored and remembers their mapping in a user-configurable way
   • Another problem would likely be the “single-instance” feature of KeePassXC which only allows one database to be open at a time (correct my if I'm wrong!)
   • An initial implementation could likely get away with just punting on this feature entirely and only supporting the default collection which basically all apps seem to use
     3. Running the secret storage daemon as a separate application is not only possible, but also preferable in my opinion since it keeps the KeePassXC core smaller and results in a clear boundary between core and this platform integration (Apple has a similar thing for instance, but see the next bullet however!)
   • Also doing it this way would allow for another cool feature: Unlocking the default KeePass database file using the login password (only GUI-less applications can do this and KeePassXC is not one of them)
     4. In order for client connection/password auth prompts to work correctly the mediator service will have to map each secret-service session created to a separate connection between the mediator and KeePassXC and provision a different secret key for each “application”
   • An initial implementation could reuse the same secret key for all client applications instead, then add the per-application provisioning later on
   • Nit: What is an “application” in this context? The secret storage API has no notion of this and the best we can probably do is getting the binary name for any client when they open a session by using GetConnectionUnixProcessID on their sender-ID and converting it to a binary path using readlink /proc/$pid/exe, this would then determine their respective secret key
     • This comes at the major drawback that interpreted applications (think Python) will all share the same binary name (/usr/bin/python3.7) and hence share the same client key – as far as I know there is no good fix for this
     • Additionally upgrading a system upgrade may upgrade the Python (or whatever) version from, say, Python 3.6 to 3.7 causing a new binary name to appear: /usr/bin/python3.6 vs /usr/bin/python3.7 – this will need to be handled
     • In order to distinguish between clients we could use /proc/$pid/cmdline but this can be (and actively is) manipulated by processes – from a user's perspective it is likely still helpful, but we then place trust on users not installing untrusted junk without sandboxing (a trad-off and worst-case we'll be off as badly as when we didn't have this extra facility at all)
     • Appros sandboxing: Getting a sane, and secure, App-ID for Flatpak'd apps appears pretty simple
   5. There does not seem to be any documentation of KeePassXC's native protocol, which is bad (but there are some client libraries that should ease the pain and provide some ad-hoc documentation here)

If there is interest I'll try providing a time estimation (in hours) for throwing together a suitable proxy/bridge application that exposes the currently open database as default collection.

[jo-so]

I thought the service would work like the current remote access and query me, if a request is valid and which credentials should be send. A GUI-less service sounds good, but I prefer to acknowledge the approvals.

[kakra]

@alexander255

Well, here we go: https://www.bountysource.com/issues/53971701-make-kpxc-databases-accessible-via-libsecret-dbus

I'd prefer if the bounty would also mention KDE integration, not just Gnome...

[virtualdxs]

@kakra Only @kwill can change that. It's the issue text. Either way, they're not separate tasks.

[Skycoder42]

@kakra The SecretService API is generally independend of the Desktop Environment, as it is simply a standardized Specification by the Freedesktop foundation. Integration with GNOME/KDE specific applications has to be done by the developers of those and is seperated from the development of the service itself.

Also, I haven't seen that specification linked here (Might have overlooked it though). So here it is: https://specifications.freedesktop.org/secret-service/

[kakra]

@Skycoder42 Having a spec that says it's independent of the DE implementation doesn't mean it shouldn't be tested. After all, we may also find bugs in KDE's implementation of the interface (which wouldn't surprise me too much because almost everything I find using secret-service seems to be built around Gnome).

[ntninja]

@jo-so:

I thought the service would work like the current remote access and query me, if a request is valid and which credentials should be send. A GUI-less service sounds good, but I prefer to acknowledge the approvals.

The GUI-less only refers to the fact that the bridge itself would not engage in any kind of window displaying activity, but since that particular window is already being and would continue to be presented by KeePassXC nothing would change on this front and you'd continue to see the authorization prompts as usual. That said: KeePassXC would likely display all requests as originating from the bridge rather than from the respective application responsible for the request. This could likely be sidestepped however by making each secret service session correspond to a separate connection between the bridge and KeePassXC with a per-client binary association. I'll update my notes with information about this – planning for this early will make a proper implementation of much easier later.

[ntninja]

@kakra @Skycoder42:

I'd prefer if the bounty would also mention KDE integration, not just Gnome...

I hate to be that guy, but one very important limitation regarding KDE here is that most “KDE-native” applications (most importantly the KDE-PIM/Kontact suite and KIO) still do not actually use the libsecret/SecretService API but rather KWallet which does not in any way interact with the secret storage API.

To highlight this, since I saw the opposite being claimed here as well: KWallet has nothing to do with libsecret, hence none of this discussion will change anything about it!

Now, you may be saying “What about KSecretService?” Well, KSecretService does not exist (that Wiki page is actually quite representative of the project in an ironical sense) except for an early proof-of-concept from 2010. See also this KDE bug for the current “status” – and yes that's me in that bug talking about dumping the project altogether.

Of course none of this precludes KDE project switching away from KWallet if there is a suitable alternative, but that's the status quo. The alternative would be to re-implement libkf5wallet5 to use the KeePassXC interface instead, but that is definitely not in scope of this issue/project.

Sorry if this raised any false hopes!

[kabili207]

Thanks for pointing that out @alexander255. There's nothing wrong with being "that guy." I had based my comment off the freedesktop Secret Service page that listed the KDE Wallet devs among those who developed the API, but hadn't bothered to check if they had actually implemented it.

Considering the fact that the 0.2 spec hasn't had a meaningful update since 2011, I highly doubt KWallet will be updated to support the Secret Service API anytime in the foreseeable future, so I'd agree that anyone seeking compatibility should submit an issue requesting support.

[intika]

An other bounty for KDE ? lol

I guess a good implementation would be an upstreamed KDE compatibility with the keepass system (in kde wallets management) libkf5wallet5 + kwalletmanager5 but this would be even more work than libsecret...

Any way KDE does not need Keepassxc as much as Gnome Keyring

One important thing while developing this feature if possible is keyring isolation which does not exist on the current gnome keyring (one application requesting credentials can access all the content) may be after the initial release... just my 2 cents

;)

[ntninja]

One important thing while developing this feature if possible is keyring isolation which does not exist on the current gnome keyring (one application requesting credentials can access all the content) may be after the initial release... just my 2 cents

I've just spent the last 1,5 hours trying to define what app isolation would even mean in this context. :slightly_smiling_face: A TL;DR may be in order:

• We can only securely distinguish running binaries from one-another, script-based applications will be reduced to their respective scripting language interpreter and any further subdivision would be based on the respective application author's good will
• Sandboxed applications (Flatpak) are not harder than distinguishing binaries from one-another and should reliably work no matter what they contain

In this context isolation means: “If a new application tries to use an existing password a prompt will be displayed” – All applications still have access to everything with user consent (there are no separated namespaces).

[kakra]

@alexander255 Please don't hate being that guy. This is valuable information. The pure existence of that said wiki page adds to the confusion, including the fact that my system had once this API bridge from the proof-of-concept project installed. That explains something, as I was wondering lately why Gnome apps do not see my wallet passwords.

So in the end it's "that topic again": One other project of KDE silently vanished as not being continued.

@intika If there should be one bounty, maybe one that revived that old proof-of-concept project and turns it into a first class citizen? I'm not sure why this project has been suspended. Did it encounter major incompatibilities with the KDE ecosystem? Was it just too early and the secrets API hasn't developed enough yet?

[kabili207]

@kakra The original dev who worked on it stopped because of kdelibs splitting into KF5. The person who re-started work on it in 2015 dropped it about a year later because he no longer had the time.

[ntninja]

@kara Thanks! Do, by bridge, mean something that exposes a SecretService implementation and forwards those requests to KWallet? If so, reviving it won't do any good as it be forwarding stuff in the wrong direction: You need something that translates from KWallet to SecretStorage, not the other way round.

Also from the discussion @kabili207 linked it appears like KWallet is actually a D-Bus API as well? At least some quick tests seem to confirm this. Also this appears to be the entire client library and one see an incomplete implementation of a SecretStorage based backend there. Both, completing and activating this backend, or reimplementing the D-Bus API of course remain issues not directly related to this one, but they highlight possible ways forward.

[kakra]

@alexander255

You need something that translates from KWallet to SecretStorage, not the other way round.

Ah... Yes... I think I'll still have one system available that uses the GPG-based encryption that was mentioned in the mail @kabili207 linked. I may be able to inspect that tomorrow. But you're true: It's the other way around, KWallet would be translated to SecretStorage.

[ntninja]

I've pushed an estimate on the price of this project to BountyHunters: 22 hours of work of which 4 hours are the required research (already done, see my first post) and 18 hours (or 3 days @ 6 hours a day) for implementation at a wage of 10$/h.

The implementation will cover:

• The main mediator service two-way translating SecretStorage API calls to the KeePassXC browser protocol including the highly recommended bus-level encryption

The implementation may cover:

• Client-level isolation – if it doesn't only the key provisioning and app identity detection will be missing making it easy to fix this later on
• Automatically unlocking KeePassXC with the login password – probably won't happen within the budgeted timeframe, but I may add it anyways 'cause it's a cool feature

The implementation will definitely not cover:

• Non-default collections (which would effectively expose multiple databases over the bus at the same time)

[virtualdxs]

@alexander255 Regarding Automatically unlocking KeePassXC with the login password: I love this idea. I will say though, it seems like it deserves its own issue.

[ntninja]

Yes, probably. But the way to do this afaik is to spawn off a service during PAM's session phase that will then store that password in memory and forward it to KeePassXC once that has been started. That service could IMHO be the proposed SecretStorage bridge, since it's basically what will do “Linux integration” anyways.

[virtualdxs]

I see, that makes sense then to keep it in this issue if that's how it's to be implemented.

[jo-so]

The implementation will cover:

• The main mediator service two-way translating SecretStorage API calls to the KeePassXC browser protocol including the highly recommended bus-level encryption

Why we need a new service? Couldn't be the SecretStorage API implemented in KeePassXC itself? Why we need to go the way through the browser protocol? What lacks the SecretStorage API that makes it necessary to got through the browser API?

[ntninja]

@jo-so:

Why we need a new service? Couldn't be the SecretStorage API implemented in KeePassXC itself?

We don't need a new service and of course all of this can be implemented as part of KeePassXC core itself. My rationale for going implementation is this:

Running the secret storage daemon as a separate application is not only possible, but also preferable in my opinion since it keeps the KeePassXC core smaller and results in a clear boundary between core and this platform integration (Apple has a similar thing through a totally different API for instance)

Please outline why you think it's preferable to stuff it all in one big binary. I'm genuinely curios. :slightly_smiling_face:

Why we need to go the way through the browser protocol?

Because it's the only supported protocol (with KeePassHTTP and KeePassRPC being deprecated/dropped)?

What lacks the SecretStorage API that makes it necessary to got through the browser API?

Nothing, they map pretty well actually. The browser protocol is better insofar as that it forces clients to provision their own HOTP key for encryption and authentication rather than regressing to a basic “if it can connect, it's trusted for everything”. See point 4 of my proposal/notes on my ideas on how this can be implemented (within certain limits) based on the sender's identity however.

I will admit however that provisioning those keys inside the bridge however is not ideal, but it's not like we can upgrade the existing SecretStorage protocol with this property.

[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