Native helper application

[luckyrat]

Create a separate helper application for Kee to communicate with, instead of direct WebSocket communication with the KeePassRPC server.

This will allow KeePass to be launched from the browser and potentially allow concurrent KeePass instances to be supported without the need for manual TCP port configuration at both ends.

• Must not prevent existing WebSockets KPRPC client from functioning.
• Will be launched by the browser and follow the lifecycle of the WebExtension in the browser.
• More than one may be running at the same time.
• Needs to be able to:
  • Launch KeePass if it's not running
  • Connect to KeePassRPC server
  • Ideally, detect presence or not of the KeePassRPC plugin (e.g. by determining that a KeePass process is active but KeePassRPC is not listening)
  • Proxy all KPRPC requests between Kee and the KeePassRPC server.
• Could adjust usage of the agreed communications port to just initial handshaking and then hand off later communication to a different port in order to better support multiple instances and multiple user sessions running KeePass concurrently?
• Will likely require changes at both ends of the existing KeePassRPC connection to ensure that connection status can be correctly reported to the user.

I have no plans to implement this at the moment but welcome either "reaction" feedback on this issue or offers to implement it from other people. For me, just using the built-in "Run KeePass at Windows startup" option will likely be good enough but I'm happy to advise and review implementations of a native application if anyone else feels strongly about the need for any features that this native application will enable.

[Aetf]

If launching application isn't possible in new versions of Firefox, how would you launch such a native helper?

[luckyrat]

The browser would do it for us: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_messaging

We have to use a separate application though, rather than KeePass itself because we don't control the command line I/O for KeePass.

[Aetf]

Interesting, I didn't know that API before. Thanks for clarifying. :)

I'm just asking out of curiosity though, since "run at start up" options works fine for me...

[johgoe]

Is there a reason to keep KeePassRPC instead og keepasshttp like the chrome plugins does?

[mygithuber]

Maybe this helps calling external programs (like KeePass) from inside Firefox-57:

Same problem with FDM (Free Download Manager). Its AddOn uses a helper called 'native client' with node.exe for starting FDM...

https://add0n.com/download-with.html?from=fdm https://www.freedownloadmanager.org/

[luckyrat]

https://github.com/smorks/keepassnatmsg might provide some inspiration to anyone that wants to take this on.

It apparently embeds a native helper application installer within the plgx. It's not clear how easily it can be repurposed to work with KeePassRPC but it's really the native messaging STDIN/OUT stuff I currently have no clue about so that's probably not a big concern.

[luckyrat]

As a fix for the security problem (but not necessarily any of the workflow problems) would you accept a commit for a helper application that basically just sends the websocket text over something like a bidirectional named pipe, and then modifies the plugin to have an option to turn off the network socket interface and open a named pipe instead?

Browser extensions aren't able to directly communicate over a named pipe so the helper application would need to use the native messaging API helper as mentioned above.

An option to switch between the websocket and native messaging API connection is a good idea, allowing us to roll out a new version of the plugin with the new connection type as an opt-in feature, before making it the default and then eventually removing the websocket code altogether.

I would happily accept a PR even if it omits some of the workflow improvements, providing that it doesn't preclude us from adding those in the future and providing that it doesn't introduce other regressions in the experience for KeePass or Kee Vault users.

It's the interaction between the browser extension, native messaging API, helper application and then KeePass/KeePassRPC that is most unknown to me so I suspect that if a PR resolved that complexity, I would be able to introduce additional workflow and user interface improvements relatively quickly and easily.

[luckyrat]

Firefox 87 will add support for the nativeMessaging permission being optional (https://bugzilla.mozilla.org/show_bug.cgi?id=1630415).

Since Chromium already supports that, this might help us with a smooth rollout to existing users - Kee Vault and the "legacy" WebSocket connection to KeePassRPC can continue to work and the user can opt-in to the native messaging connection when they are ready to do so.