search

keepassxreboot / keepassxc

KeePassXC is a cross-platform community-driven port of the Windows application “Keepass Password Safe”.
https://keepassxc.org/
Other
21.21k stars 1.47k forks source link

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

Closed lofidevops closed 5 years ago

lofidevops commented 6 years ago

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

virtualdxs commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

Awesome! :+1:

droidmonkey commented 5 years ago

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 commented 5 years ago

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