Talking to a flatpak'ed KeePassXC from native Thunderbird

[acolomb]

I haven't tested whether this only applies to Thunderbird as a native application, might be relevant for a sandboxed Thunderbird as well. But definitely, this is related to KeePassXC running as a Flatpak application.

When I enable Firefox browser integration in KeePassXC, it writes this JSON file to ~/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json:

{
    "allowed_extensions": [
        "keepassxc-browser@keepassxc.org"
    ],
    "description": "KeePassXC integration with native messaging support",
    "name": "org.keepassxc.keepassxc_browser",
    "path": "/var/lib/flatpak/exports/bin/org.keepassxc.KeePassXC",
    "type": "stdio"
}

With the instruction from the README here, it gets transformed to use the correct extension IDs, written to a new file de.kkapsner.keepassxc_mail.json, as it should. However, the path specified here is actually a flatpak launcher script which starts the application binary with the provided command-line arguments. It DOES NOT launch the keepassxc-proxy binary also contained in the flatpak.

After much digging, I figured out how to make it work, at least partially. I specified a custom script for the path: "path": "/home/acolomb/.local/bin/kpxc-proxy.sh", with the following content:

#!/bin/sh
exec /usr/bin/flatpak run --command=/app/bin/keepassxc-proxy org.keepassxc.KeePassXC "$@"

The important part here being the --command option. Of course the script needs to be on $PATH and made executable. This way, keepassxc-mail can properly talk to an already-running KeePassXC. But there is no auto-launching, as it happens with Firefox.

What I found from the process tree, the Firefox integration in fact does not launch the keepassxc-proxy binary directly, either. Instead, it uses a script called keepassxc-wrapper, which is the default command specified in the Flatpak manifest / metadata. This script explicitly checks its call arguments, and if it finds the ID keepassxc-browser@keepassxc.org in its second argument, it launches keepassxc-proxy instead of keepassxc. (It also accepts cli as first arg to launch keepassxc-cli.)

The current setup with keepassxc-mail therefore fails because it passes a different ID, launching KeePassXC trying to open a database named like the native messaging provider JSON file, instead of running the proxy binary.

All this seems very poorly documented, I had never before read about the keepassxc-wrapper script. That must be something specific to the Flatpak version, but apparently is maintained upstream?

Either way, could you @kkapsner try to get your extension ID for keepasscx-mail integrated there? That seems to be the quickest route to make it work for flatpak'ed KeePassXC.

One further step would be to make KeePassXC generate the correct JSON file for keepassxc-mail directly, as it does for Firefox. Including the right binary path (the Flatpak launcher script in this case, which spawns the wrapper script with the correct associated ID).

[acolomb]

This is probably related to #94, as I doubt the KeePassXC maintainters will include your "unrelated" application ID in their script. But it could work either way.