KeePassXC-browser native messaging does not work with flatpak

[oidualc]

Subject of the issue

KeePassXC-Browser is unable to connect to KeePassXC, likely a problem with Native Messaging. Probably relevant, the needed file org.keepassxc.keepassxc_browser.json is available in ~/.mozilla/native-messaging-hosts, but not in ~/.var/app/org.mozilla.FirefoxNightly/.mozilla. In fact the directory native-messaging-hosts is missing.

Environment

• Arch Linux
• Firefox Nightly (flatpak)
• KeePassXC (flatpak, from dl.flathub.org)

Steps to reproduce

Assuming the availability of a working instance of KeePassXC, install the KeePassXC-Browser addon and try to connect.

Expected behaviour

After having verified that on Firefox Nightly (non-flatpak) the extension works correctly, try to connect using Firefox Nightly (flatpak) and expect it working the same way.

Actual behaviour

On Firefox Nightly (non-flatpak) the extension works as intended, on Firefox Nigthly (flatpak) the error message is "Timeout or not connected to KeePassXC".

[wvengen]

You may be able to expose native-messaging-hosts e.g. by hardlinking the file to the ~/.var/... path:

ln ~/.mozilla/native-messaging-hosts ~/.var/app/org.mozilla.FirefoxNightly/.mozilla/native-messaging-hosts

Or perhaps use the --persist option to flatpak run to expose this file.

Perhaps the cleanest way would be to be able to pass some kind of --socket=keepassxc option to flatpak run, and let flatpak understand that option to expose the socket. I'd try my luck with the other options first.

[oidualc]

Hi @wvengen, unfortunately I cannot hardlink native-messaging-hosts because it's actually a directory, not a file. The closest thing I can think is:

mkdir ~/.var/app/org.mozilla.FirefoxNightly/.mozilla/native-messaging-hosts
ln ~/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json ~/.var/app/org.mozilla.FirefoxNightly/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json

but even like this it doesn't work.

With regard to the --persist and --socket=keepassxc options I don't know enough about flatpak to understand what I could try.

[kaymio]

Hi @oidualc @wvengen ,

has someone achieved any progress on this front. My setup is very similar.

Arch + flat FF DevEdition + flat KeePassXC I know that my KPXC instance is working correctly because my natively installed FF works just fine with the flatKPXC.

[rugk]

@oidualc Can we maybe change the title of this issue to something like "KeePasssXC-browser' native messaging does not work with flatpak", which is more specific than the current one?

[rugk]

BTW a workaround has been provided in this issue (or here) that works if KeePassXC is also installed as a flatpak. (Edit: Or possibly it does not… Only works if flatpak is installed on the host… :thinking:) Edit2: Or no, you can get it to work securely. See https://github.com/flathub/org.keepassxc.KeePassXC/issues/13#issuecomment-372030281. The issue is fixed, so it should work. :smiley: (with the only adjustment already linked - the wrapper script)

[kaymio]

Thank you @rugk for your effort to solve this issue.

With the wrapper script my native FF doesn't start KeePassXC in parallel, as intended.

The flatpaked version of FF (this repo) still doesn't connect to the flatpaked KeePassXC.

[rugk]

Okay, hmm. Note I have also been advised that DBUS could be used to spawn another process, but AFAIK this is a thing that would have to be baked in, into this browser flatpak. (@xhorak, are you listening?)

@kaymio If you want to try it, you can create the following wrapper script as a workaround somewhere accessible to the Firefox flatpak (and keepassxc too, AFAIK, so in the worst case use /opt or maybe better your home dir?):

#!/bin/sh
flatpak-spawn --host keepassxc-proxy "$@"

I've based this loosely on my other scripts here.

Then flatpak override this.app.ID --talk-name=org.freedesktop.Flatpak (Attention: this allows this flatpak to start any commands on the host!) and then point keepassxc-browser to start this script instead of keepassxc-proxy.

This should allow Firefox to spawn a keepassxc-proxy on the host, so if keepassxc runs on the host, it works.

So now, you may want both (also KeePassXC) as flatpaks. So we also need to do step 4 here, which may end up in a script like this:

#!/bin/sh
flatpak-spawn --host /usr/bin/flatpak run --command=keepassxc-proxy --branch=master --arch=x86_64 org.keepassxc.KeePassXC "$@"

I am just not sure whether the whole thing with unix sockets and so on still works. In any case, take these as ideas, I guess it won't work exactly like this and there may still be bugs.

[kaymio]

Unfortunately my skill level is not high enough to meddle that deeply with the system. Especially if it goes that deep:

(Attention: this allows this flatpak to start any commands on the host!)

Nonetheless, thx!

PS: There was some movement during the flatpak update today. Although it finished with an error. Error: Message recipient disconnected from message bus without replying. Also the build still relies on Gnome 3.24 which is deprecated as of 11th January. Don't know whether I should file a bug report.

[rugk]

Don't know whether I should file a bug report.

Unless it is fixed in the next second, yes. :smile: (also noticed that issue already)

[Ramblurr]

@rugk your solution works for a flatpaked-firefox and a host-keepassxc, but it allows firefox to run arbitrary commands on the host, which severely reduces the benefit of running FF in a flatpak. :/ any idea how to restrict it further?

[rugk]

Well… unfortunately I do not have any better idea. Because you need to grant Firefox host execution permissions or it just does not work, as it needs to spawn a command. :thinking:

[rugk]

Okay maybe another idea I am not quite sure whether it works: AFAIK KeePassXC also supports some kind of "reverse connection", where KeePassXC actually spawns the proxy. This way KeePassXC could possibly spawn it inside of the Firefox flatopak. (via flatpak enter) But whether that works is another question. :thinking:

[rugk]

FYI, for everyone following: I have found a working around involving some manual steps you need to do though for KeePassXC<->Firefox communication, if Firefox is flatpaked/sandboxed (works if KeePassXC is sandboxed or not). Read the full write-up/tutorial here.

[erAck]

This can not be soved in flatpackaging. There's upstream issue https://bugzilla.mozilla.org/show_bug.cgi?id=1621763 for native messaging in flatpak. Use rugk's workaround.