Python module and commandline client

[cryptomilk]

Hi,

this is more or less what I'm looking for. Why not name this project python-keepassxc and provide a python module and a command line client.

I would like to use that protocol to query passwords on the command line, e.g. to get the password for my backup job. So I have more or less in the end

keepassxc-query --url 'sftp:mars:/backup'

and then I'm asked in keepassxc if the command line client is allowed to retrieve the password.

[hrehfeld]

Aren't there a bunch of cmdline tools yet? If not, take a look at https://github.com/hrehfeld/python-keepassxc-browser/blob/master/test.py , it's a working example. Feel free to use the library and the example to build a cmdline client, it shouldn't be a lot of work -- but I would prefer that you put it in a separate repo that then uses this library. (Please ping back though ;-))

…

On 14 February 2019 08:27:19 CET, Andreas Schneider ***@***.***> wrote: Hi, this is more or less what I'm looking for. Why not name this project python-keepassxc and provide a python module and a command line client. I would like to use that protocol to query passwords on the command line, e.g. to get the password for my backup job. So I have more or less in the end `keepassxc-query --url 'sftp:mars:/backup'` and then I'm asked in keepassxc if the command line client is allowed to retrieve the password. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #1

[Phidica]

Hi. I'm also looking for a Python library exactly like this, and very nearly didn't find it and ended up writing the whole thing myself in a considerably worse fashion! It would be awesome if this code had some documentation and was perhaps listed on the PyPI :) Thanks a lot!

Also, I would second the idea of naming it "python-keepassxc", and I'd further suggest dropping the "http" from your directory. The API has nothing to do with HTTP any more and it just encourages confusion with the deprecated "KeePassHttp" protocol (which is why I nearly ignored this repo in the first place)

[Phidica]

So my perspective was that the protocol was called "KeePassXC", and hence this repo should just be named python-keepassxc. I based that in part on the only real documentation of the protocol being called keepassxc-protocol. It seemed to me that "KeePassXC-Browser" was specifically the name of the web browser plugin, and it shouldn't also be the name of the protocol. Even though the protocol was written for the web browser plugin, it can easily be used by other applications and it wouldn't be named after the plugin

However now after playing around with the library a little more, I've realised that new logins created via this protocol are always placed in the "KeePassXC-Browser Passwords" group, which by analogy to the old "KeePassHttp Passwords" group clearly suggests that the protocol is called "KeePassXC-Browser". So by that token, the name of this repo is correct

However, I continue to believe that the library should be called keepassxc_browser rather than keepassxc_http. It seems very misleading otherwise

Would you be open to accepting a PR for this change? I'd be happy to make it, as well as create a basic readme and setup script

[varjolintu]

However now after playing around with the library a little more, I've realised that new logins created via this protocol are always placed in the "KeePassXC-Browser Passwords" group, which by analogy to the old "KeePassHttp Passwords" group clearly suggests that the protocol is called "KeePassXC-Browser". So by that token, the name of this repo is correct

With KeePassXC 2.4.0 you can select the group for saving new credentials. See keepassxreboot/keepassxc#2637.

Updated protocol from the browser extension PR:
https://github.com/keepassxreboot/keepassxc-browser/blob/e3d325a0e65569f293680e4ba291a235f9d17630/keepassxc-protocol.md

[Phidica]

My concern is not that there wasn't a control for where such passwords are stored. My concern is the semantic question of what the appropriate name for the protocol, and hence this library, is

[varjolintu]

I understand. Just wanted to give a heads up for that feature.

[hrehfeld]

There is also more general support planned for implementing libsecret in keepassxc, so there will be one more protocol on the keepassxc side. I'm definitely open to name changes, but my view on the name is different: `[<lang>]_<application interacted with>_<application protocol type>` Resulting in `python_keepassxc_http` But you're correct in that the repo name is inconsistent with this. Maybe `keepassxc_browser` would indeed be the better name.

…

On 11 March 2019 15:26:29 CET, "Sami Vänttinen" ***@***.***> wrote: I understand. Just wanted to give a heads up for that feature. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #1 (comment)

[Phidica]

I'm probably just not very cluey about this topic, but I have to ask and hope you can enlighten me: is the "application protocol type" really HTTP? As far as I can see, we're just sending and receiving JSON strings between KeePassXC. To my eye, there is nothing which looks like a HTTP packet involved anywhere in this.

And even if technically this protocol is HTTP, all the KeePassXC documentation I've seen hasn't ever referred to it as that. Their message is basically "KeePassHTTP deprecated in favour of KeePassXC-Browser". So from there on out KeePassXC users are under the impression they must ignore tools with "HTTP" in the name and seek tools with "KeePassXC" and/or "Browser" in the name. Simply for the purpose of making it easy for those people to find this library, and further software which is derived from this library, I think that using the terminology that KeePassXC uses is the most appropriate choice. Hence that is "keepassxc" or "keepassxc_browser"

[hrehfeld]

I guess I didn't make it clear before: I agree, it should be named browser instead of http. Can you prepare a PR?

…

On 12 March 2019 10:56:50 CET, Violet ***@***.***> wrote: I'm probably just not very cluey about this topic, but I have to ask and hope you can enlighten me: is the "application protocol type" *really* HTTP? As far as I can see, we're just sending and receiving JSON strings between KeePassXC. To my eye, there is nothing which looks like a HTTP packet involved anywhere in this. And even if technically this protocol *is* HTTP, all the KeePassXC documentation I've seen hasn't ever referred to it as that. Their message is basically "KeePassHTTP deprecated in favour of KeePassXC-Browser". So from there on out KeePassXC users are under the impression they must *ignore* tools with "HTTP" in the name and *seek* tools with "KeePassXC" and/or "Browser" in the name. Simply for the purpose of making it easy for those people to *find* this library, and further software which is derived from this library, I think that using the terminology that KeePassXC uses is the most appropriate choice. Hence that is "keepassxc" or "keepassxc_browser" -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #1 (comment)

[Phidica]

Ah, my apologies for the misunderstanding then.

I'll work on a PR 🙂

[hrehfeld]

Awesome, thanks! :-)

…

On 12 March 2019 15:45:38 CET, Violet ***@***.***> wrote: Ah, my apologies for the misunderstanding then. I'll work on a PR :slightly_smiling_face: -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #1 (comment)

[hrehfeld]

A commandline client should be a separate project.