Simple alternative in C# (dotnet core)

[mauron85]

I hacked simple alternative for python script in C# - dotnet core. Mostly intended for Windows user, but development and testing was actually done in Ubuntu 16.04. It doesn't have any dependencies as it is dotnet self contained app. Also it doesn't show any unnecessary dialog as python script.

More information and source:

https://github.com/mauron85/chrome_native_messaging_host

[varjolintu]

Actually this project was originally a Qt project in favor of a cross-platform solution. For some reason certain messages were always corrupted so I ditched the solution. I think Python is not so great for an easy cross-platform solution for a proxy, so maybe I'll get back to the Qt version, but without Qt's own packet serializer so it would be easier to do what you just did, write your own proxy :)

[mauron85]

What IDE are you using for QT development? I never developed for Qt, but would like to start a bit, so I'm looking for IDE with UI designer. I know, there was QtDesigner by Nokia, but it seems it's not free anymore.

[varjolintu]

Qt Creator. It's free for GPL licensed projects.

[varjolintu]

Nice and simple code btw. Did you use Mono for compiling the source under Linux? I'm not so familiar with the current state of C# in Linux.

[mauron85]

To be honest I never coded in dotnet before, neither Win or Linux, but wanted to try dotnet core under Linux. No I didn't used mono. I used docker image https://github.com/dotnet/dotnet-docker. There is complete toolchain in one single container (will not mess your system with mono libs) and the best thing is, you can create stand-alone apps for multiple platforms. Standalone apps includes all required runtime libs, so even your users don't have to install anything. Dotnetcore is limited to cli and asp.net apps though.

[varjolintu]

This is a really nice solution. For this "official" project I'm leaning towards a Qt solution, especially if keepassxc-proxy will be bundled with the KeePassXC release and binaries.

[mauron85]

Sure. I agree. This is not intended as official solution.

[varjolintu]

Still, I like the idea and the simplicity very much :)

[mauron85]

Just realized that my proxy and also probably python version both might have same bug.
Didn't investigate it too much, so I might be also wrong. But I'm having issues and only possible suspect is way, how proxy communicate with KeePassXC - synchronously (ignore fact UDP suppose to be asynchronous).

So how current implementation of proxy work:

1. Browser send request from stdin, which is proxied by proxy to KeePassXC app via UDP.
2. Proxy wait for response from KeePassXC via UDP and proxy response back to browser via stdout.

So basically what it's loop with two steps. 1. and 2.

But if response from KeePassXC never comes back, because KeePassXC is not open or user declined to accept dialog, proxy is deadlocked. Cannot accept new requests as it's waiting for response, which will never come.

The fix should be easy and possible.

Remark: I might be also wrong here. Just thinking out loud.

[mauron85]

Ok fixed in my variant of proxy by adding socket receive timeout. If proxy doesn't receive response in 5 seconds it will throw SocketException: Connection timed out, but is still able to process any additional requests. mauron85/chrome_native_messaging_host@54a63c7

Edit: But two more issues popped up. :(

1. When you close KeePassXC app and open later, you'll not be able to retrieve passwords anymore. Here is the log of communication. First is the request from keepassxc-browser and second message is response from KeePassXC. This is probably due KeePassXC private key is invalid and new key exchange should be done. Not sure how to do it.

[DEBUG] req received: {"action":"get-logins","message":"i/UDP5gXXYcNXhZT/g281E5AuYodZG3IKIIR5885G/SKTeVqI6lJrM+FB73tpW4vYpjPMu3N6TMxfMzlHwFemhXlWqhV1H68HXPjc1vU0DAfAJg2jQSH18uIVBFy/c4cuceoYkyNRW70UHGVeB9hqpqfJlbIUT2PH6tSzhlvdDADNhXyVx4kJQZhpbIxHw==","nonce":"MMhirAteq+5wK0NDEzv40Kf7fWPzakTw"}
[DEBUG] resp received {
    "action": "get-logins",
    "error": "Cannot decrypt message",
    "errorCode": "4"

2. After socket receive timeout messages, new messages are not read correctly from stdin.

[DEBUG] req received: Cw"}{"action":"get-logins","message":"3N3NBmHGxGUQ0PfOnroAiNtN6Pqy8gEGQtA8mrvFFj7p17Vl1wgGRtX7TtRHTIVmocYDMELzNSYLoatgvTRrWon9idWXZFPFx//mWADN3ya3+sU02gyWsVvq4LfW4CqiPMGu7ZknqS5Miwwu6l6PyJp8loR55V1XVANCpDTm6ThrO6vXhPk61BuGorw5Aw==","nonce":"2J16zt1S7BiuYpIUJqxSwFfmJ/T+u7
[ERROR] parsing exception: Newtonsoft.Json.JsonReaderException: Unexpected character encountered while parsing value: C. Path '', line 0, position 0.
   at Newtonsoft.Json.JsonTextReader.ParseValue()
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.ReadForType(JsonReader reader, JsonContract contract, Boolean hasConverter)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)
   at Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)
   at Newtonsoft.Json.JsonConvert.DeserializeObject(String value, Type type, JsonSerializerSettings settings)
   at Newtonsoft.Json.JsonConvert.DeserializeObject[T](String value, JsonSerializerSettings settings)
   at chrome_native_messaging_host.Program.Main(String[] args) in /native_messaging_host/Program.cs:line 27

So it's more complicated then I thought ;-) But getting there.

[varjolintu]

Thank you for finding the same bug I'm currently investigating :)

If you look the Python script you can see the socket has a five second timeout. For some reason I couldn't get the Python thread with UDP receiving work properly. And I admit I'm not an expert with Python, so there's probably something I'm forgetting.

I also wondered why stdin messages are being corrupted. Actually this doesn't happen in the Python script but messages are corrupted in the Qt version. I'm not sure if it has something to do with the Boost libraries. Maybe I'll try to switch to Qt's own UDP socket library.

The decrypt error is because KeePassXC received a public key from keepassxc-browser every time keepassxc-browser is started. And this where it comes back to showing the correct status. Currently this is a situation which is unrecognized. If keepassxc-browser receives that error it should be noted and new keys must be exchanged. Sometimes you can see a "Reload" button in the popup. But just using that is not reliable. I will fix that to the next version (tomorrow maybe). It should work in a way that if keepassxc-browser received that error it transfers new keys to KeePassXC before next request.