Keepassxc: Provide org.kde.kwalletd5 dbus interface

[cryptomilk]

KDE uses the kwallet password manager to provide a DBUS API for password storage. For this they don't use the org.freedesktop.secrets API but have provide their own via org.kde.kwalletd5.

There have been efforts to move to org.freedesktop.secrets since 2013 but nothing has happened yet [1].

Till KDE supports org.freedesktop.secrets it would be great if keepassxc would provide the DBUS API of kwallet.

Expected Behavior

Provide org.kde.kwalletd5 DBUS API

folderList
entryList
writeEntry
writePassword
readPassword

Current Behavior

Doesn't provide org.kde.kwalletd5 DBUS API

[1] https://bugs.kde.org/show_bug.cgi?id=313216

[droidmonkey]

I'm not keen on supporting a one-off "standard" that needs to be replaced by the actual standard.

[cryptomilk]

FYI https://marc.info/?l=kde-devel&m=146788782429932&w=2

[Aetf]

I'm on the KDE desktop and I've been using KeepassXC as the libsecret provider for a while (since I implemented it :P).

KDE applications are luckily flexible enough that many of them can be configured to use libsecret-based API either via settings or via some environment variable which they use to detect the desktop environment. This includes chromium-based browsers and many electron apps.

There are still a few things before I can disable kwallet system-wide:

• KCM Online Accounts, this saves google accounts credentials if you want to use kio-gdrive
• Network manager, when wireless passwords are saved for the user only

I'm now playing around with signon, which is what KCM Online Accounts uses for secret saving, which can be configured to use libsecret backend. I'll update once I feel it's good for everyday use.

For network manager, I'm sure there are also some settings/envvar to tweak but I haven't look into it yet.

Anyway, the bottom line is that libsecret DBus interface can still be helpful for KDE users.

[cryptomilk]

I'm not saying it is not useful, but most apps only use kwallet like akonadi or the plasma network manager applet. It will take while till KDE fully supports libsecret.

[Aetf]

Yeah, I just feel this is kind of a chicken-egg problem. Kwallet works so well for KDE applications and there is little incentive for app/framework developers to push for the standard. I just try to start using libsecret, at least for myself, hoping it will happen a little sooner ;)

[droidmonkey]

Aetf what would it take to support this API if you could somehow detect that it was needed either on the fly or via explicit setting?

[Aetf]

From a quick glance of kwallet API, the high-level concepts look similar. Implementation-wise, some shim code is needed as the method semantics are probably different.

Detection on the fly doesn't make sense because it's the other way around: the client checks if any service is available at the predefined DBus address. But it's possible to register both DBus addresses (kwallet and libsecret) at the same time and expose methods correspondingly. This can be covered by a setting.

So, in theory, one could have KeepassXC acting as both a libsecret provider and a kwallet provider. But don't expect passwords set by different APIs to be compatible. Maybe better to use to separate groups for each API.

[droidmonkey]

Yah that is too messy for me... if you think of a clean integration we can consider it, but I don't think it is worth the effort.

[azrdev]

Building the sim standalone sounds more feasible, i.e. an extra application providing the kwallet API but only proxying to the libsecret one.

[0xpr03]

Just to leave a plasma-user voice: I just use keepassxc as the main manager, if an KDE applications requires credentials I'll provide them via autotype/copy 'n paste, that's it. Even more I'm quite okay with kwallet getting used for WiFi as I don't see why I need to unlock my complete keepass just for my WiFi to run after logging in. At least to me it's a huge difference between unlocking my WiFi and unlocking my global password manager.