Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: Keepassxc client library #2546

Closed
Skycoder42 opened this issue Dec 12, 2018 · 9 comments
Closed

Suggestion: Keepassxc client library #2546

Skycoder42 opened this issue Dec 12, 2018 · 9 comments

Comments

@Skycoder42
Copy link

Skycoder42 commented Dec 12, 2018

I am planning to use the new browser extension API in a desktop application to communicate with keepass and retrieve credentials etc. For this I would of course need a "client library" of some kind, preferbly in C++

My Questions here are:

  1. Is there already a (official) library that implements the client side of the protocol (except of the actual browser plugin)
  2. If not, would you be interested in one. I will create one anyways, but if you think this would benefit the project as a whole, I could create it as a PR to contribute it. I am asking beforehand as a PR would mean I have to follow the coding style etc. of KeepassXC

Expected Behavior

There should be a client library for the extension API

Current Behavior

There is none

Possible Solution

I would create a static library that uses libsodium to communicate with keepassxc(-proxy) via stdin/stdout and provides a simple C++ interface to the protocol described in keepassxc-browser. In case of a contribution, it would be designed as "stl-oriented" library and use no additional dependencies. If wished, I could also formally describe the API and library design beforehand and share it here for feedback and documentation.

Context

Since KeepassXC does not support plugins in a ways that the original keepass did, integration with other services is somewhat limited. Providing a client library would give us a secure and easy way to create such integrations, without the dangers that loading plugins traditionally bring with them.

@droidmonkey
Copy link
Member

We have the proxy (keepassxc-proxy) which is a middle layer relay that is launched by the browser. This is so multiple proxies can be launched to communicate with a single KeePassXC instance, but it is entirely optional. You can directly communicate to KeePassXC via native messaging without the proxy. Within KeePassXC is the code that processes the native messages: https://github.com/keepassxreboot/keepassxc/blob/develop/src/browser/BrowserAction.cpp

You could just copy that code and some other bits and pieces and slap them into your application or create a library. Unfortunately it is rather tightly bound to KeePassXC, so you would have to replumb it for your application.

@Skycoder42
Copy link
Author

Skycoder42 commented Dec 12, 2018

@droidmonkey Thank you for the hints, but I already found out that much by myself. I have a "proof-of-concept" application already implemented that performs the first few steps (i.e. key exchange and association). So this is not really a question of whether this is doable, but if you guys want it to be part of this project. I only asked if you know of an existing library to make shure the work of creating one is not done twice

@droidmonkey
Copy link
Member

droidmonkey commented Dec 12, 2018

No we do not have a library specifically for the protocol. What is the project?

@Skycoder42
Copy link
Author

For now I only have a console app that performes those two steps on my local machine. But the eventual library is planned to be used for the KeepassTransfer project - I am currently reworking that project but haven't updated the readme etc. yet

@Skycoder42
Copy link
Author

I have now created and released a first version of such a library - See keepassxc-client-library.

The library depends on QtCore, mostly because of QProcess, QJsonObject and the advantages of signals/slots. Currently qmake is used as build system, but only because I am more familiar with it than cmake. There is nothing special going on there, so porting it to cmake should be relatively easy if required.

If you want, you can have a look at it. And of course I am still interested in contributing it directly to this project, to make it more accessible to users.

@hrehfeld
Copy link

hrehfeld commented Jan 2, 2019

Maybe also see #1403 for a generic approach (on systems supporting Secret Service).

@varjolintu
Copy link
Member

I quickly made a simple Python client library for this. Feel free to collaborate.
https://github.com/varjolintu/keepassxc-browser-client

@hrehfeld
Copy link

hrehfeld commented Jan 3, 2019

@varjolintu that's... really awesome! Thanks a bunch!

https://github.com/hrehfeld/python-keepassxc-browser However, I rewrote it for python3, more pythonic, thread safe(ish), fixed a bunch of bugs in encoding and math that made porting to python 3 really hard.

@varjolintu can you checkout increment_nonce() in https://github.com/hrehfeld/python-keepassxc-browser/blob/master/keepassxc_http/protocol.py#L44 ? There can be an integer overflow there (if we had int8), therefore I modulo 256 each byte, assuming C implementation will overflow -- is this correct? In general, it would be awesome to have a code-review, especially of the "crypto" parts.

@varjolintu
Copy link
Member

@hrehfeld That looks much nicer and more generic than my quick Python 2 implementation. I'm just a beginner with any Python stuff after all.

incrementNonce() is mainly a rough translation of https://github.com/jedisct1/libsodium/blob/1647f0d53ae0e370378a9195477e3df0a792408f/src/libsodium/sodium/utils.c#L282

Modulo is a bit safer approcach yes. Maybe making a separate tests for the incrementation could work minimizing the possible bugs. Another solution that's possible is to replace pysodium with PyNaCl that has nonce incrementation implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants