Unable to connect native KeePassXC to flatpak Firefox

[WineBottles]

I followed the instructions here: https://discourse.flathub.org/t/how-to-run-firefox-and-keepassxc-in-a-flatpak-and-get-the-keepassxc-browser-add-on-to-work/437 to expose Firefox/KeePassXC to each other but I am not having luck actually getting them to connect.

Steps to Reproduce

1. Downloaded the attached keepassxc-proxy and placed it in ~/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts
2. Created the file org.keepassxc.keepassxc_browser, copy and pasted the lines and replaced the path with my username where required
3. Rebooted. Started KeePassXC first then Firefox

Expected Behavior

Flatpak Firefox should be able to connect to native KeePassXC

Actual Behavior

Clicking on the KeePassXC add-on in my browser bar says:

Cannot connect to KeePassXC. Check that browser integration is enabled in KeePassXC settings.

Going into about:debugging says:

Error 5: Cannot connect to KeePassXC. Check that browser integration is enabled in KeePassXC settings. keepass.js:1187:13
Connecting to native messaging host org.keepassxc.keepassxc_browser keepass.js:1104:13
Failed to connect: Unknown error

Context

I am not sure if I need to be changing the "browser integration" settings in KeePassXC, as the article I linked at the top here says it should just work. I tried turning off and on integrated with Firefox as well as going into the advanced tab and turning off and on "Use a custom browser configuration location:

Browser type: Firefox
Config Location: /home/MYUSERNAME/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/

When I have "Update native messaging manifest files at statup" it changes

/home/MYUSERNAME/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/keepassxc-proxy

to

"path": "/usr/bin/keepassxc-proxy",

So I know that is not as expected and I should probably not use that config.

KeePassXC 2.6.6
Firefox flatpak 96.0.3

Operating System: Arch Linux
KDE Plasma Version: 5.23.5
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2
Kernel Version: 5.15.16-hardened1-1-hardened (64-bit)
Graphics Platform: X11

[droidmonkey]

You cannot use the browser extension when the browser is in a flatpak or snap. It is impossible until they introduce a plug that let's that communication happen.

[WineBottles]

You cannot use the browser extension when the browser is in a flatpak or snap. It is impossible until they introduce a plug that let's that communication happen.

I'm confused. This article discusses how to connect KeePassXC and Mozilla Firefox even if both are. I had only did the half part because KeePassXC is native.

"Hooray!: For those, who install KeePassXC on the host (without any sandbox/flatpak), this is enough. Start KeePassXC and then Firefox and it should be able to connect. 🎉
Please note the “existing problems” section at the bottom, though."

https://discourse.flathub.org/t/how-to-run-firefox-and-keepassxc-in-a-flatpak-and-get-the-keepassxc-browser-add-on-to-work/437

[droidmonkey]

That isn't posted by our team and I have no idea if it still works. You are on your own here.

[remyabel2]

@WineBottles flathub/org.keepassxc.KeePassXC#29

[zeitisen]

Unfortunately there is no native Firefox anymore with Ubuntu 22.04. Even if you install from packet with apt, you end up with a snap. So what now?
Should I change to Windows or to Chromium? Or setup from tar? There should be a simple solution

[droidmonkey]

Petition canonical if you want a simple solution. Snaps ain't it.

[mo8it]

@zeitisen Take a look at this guide:
https://www.omgubuntu.co.uk/2022/04/how-to-install-firefox-deb-apt-ubuntu-22-04

Maybe try Fedora in the future. It is very stable, more up to date and has no snap crap. There are many installation guides and reviews in the internet (including YouTube).
Fedora has Gnome by default. If you like Gnome, then Gnome itself recommends Fedora on the first place.

I hope that Flatpak Firefox can handle KeePassXC in the future. Thanks to the developers anyway. I know that Canonical does weird things, but I think that the users should not be blamed for not doing a new install of another distro. Lets help euch other :)
No offense to anyone :)

[westonstewart]

Ran into this same issue in the last few weeks, as I transitioned my 2012 MacBook Pro from macOS Catalina (10.15.7) to Ubuntu 22.04.1. My solution was to:

1.) Uninstall snap entirely (https://github.com/MasterGeekMX/snap-to-flatpak)
2.) Follow the manual installation instructions for Firefox (https://support.mozilla.org/en-US/kb/install-firefox-linux#w_install-firefox-from-mozilla-builds-for-advanced-users)
3.) Install KeepassXC from the Ubuntu PPA (https://launchpad.net/~phoerious/+archive/ubuntu/keepassxc)

Once Firefox and KeePassXC were installed, I added KeePassXC-Browser to Firefox ... and KeePassXC and Firefox connect as designed; indeed, this setup works pretty much the same as it did on macOS.

Other thoughts: I should note that Firefox (and Thunderbird, which I installed using the same method) receives its updates internally (going to Help > About Firefox or Help > About Thunderbird). This may not be standard Linux behavior, but it was normal under macOS (and I actually prefer it) and thus is "more of the same" for me. Having all three apps installed and working properly (without the need for either snap or flatpak) was an important goal for me ... and this browser extension issue forced me to find a solution that would work independent of those environments.

EDIT (8/23/23): This setup continues to work for me today (running Ubuntu 22.04.3), and specifically works while running Wayland (re noisystuff's post below). Although I haven't tested it with other Linux distros, it should work with KeePassXC installed via any standard package manager (apt, dnf, pacman, et cetera). It also worked for me using the AppImage version of KeePassXC, which I didn't really expect to work, but it did.

Above, droidmonkey said "Petition canonical if you want a simple solution. Snaps ain't it." I would say much the same about Flatpak, with petitons directed to the Flatpak Team. This is one use case where I think sandboxing hurts more than it helps.

[eklenin]

It would be very nice to have the way to connect keepassxc to sandboxed browser.

[noisystuff]

Hi Folks.
I like my security :-) so I'm running Keepassxc, Firefox and most other applications as Flatpak (on Kubuntu). I plan to soon use Wayland, but as we know, it won't 'permit' autotype (no API for passing characters between applications and I can't see that ever being permitted for security reasons). Looking forward, I suspect Flatpak will become more and more popular as being the default way to install graphical applications (and of course, more people will start using Wayland) so to me it would seem prudent to ponder some form of a robust solution (for a Flatpak browser addon to be able to communicate with Flatpak Keepassxc). I'm an old geezer, so ctrl+c and ctrl+v are 'muscle memory', but I'd expect gen z and the likes might expect a pointy clicky solution (just trying to raise a smile with that last comment); heck, even I'll massively miss autotype so yes, even I would like a pointy clicky solution.
All the best, Briain

[PhrozenByte]

I followed the initially mentioned guide (also on Stack Exchange) a few days ago and since it didn't work at first because the paths are outdated, I did some research and it seems like one really just needs two things today: Allow the sandboxed Firefox to access KeePassXC's socket and copy the keepasxc-proxy binary to Firefox's sandbox. It doesn't matter whether KeePassXC itself is sandboxed or not. So, in the end this is as simple as:

1. Allow Firefox's sandbox to access KeePassXC's socket: flatpak override --filesystem=xdg-run/app/org.keepassxc.KeePassXC/org.keepassxc.KeePassXC.BrowserServer org.mozilla.firefox
2. Copy the keepassxc-proxy binary to the sandbox; since the Firefox sandbox naturally can't access shared libs of the host (or even of the KeePassXC sandbox), we need a statically linked binary here; I don't know anything about KeePassXC's source code, thus I don't know whether it's possible to build the original keepassxc-proxy like that (probably needs some changes), but in the meantime one can use varjolintu/keepassxc-proxy-rust instead; it's so tiny that one can check the source code line by line themselves (I did, it's safe)...
3. Manually setup the browser extension as usual (i.e. create ~/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts and create a org.keepassxc.keepassxc_browser.json referencing the copied keepassxc-proxy, then link the extension with the database as usual)

I believe that KeePassXC could do steps 2 and 3 automatically with a new "Firefox (Flatpak)" browser type. Step 1 surely needs some documentation, but truly isn't that big of a deal.

There's one limitation though: The sandboxed Firefox can't start KeePassXC. Thus the user must start KeePassXC themselves. This is a permanent limitation for now. However, there's yet another, a little more annoying, but probably solvable limitation: KeePassXC must even be started before Firefox (this also means: if one restarts KeePassXC, one must also restart Firefox). I'm not entirely sure whether this is a limitation of KeePassXC, the browser extension, varjolintu/keepassxc-proxy-rust, or Flatpak, but following varjolintu/keepassxc-proxy-rust#11 I think it's due to both the browser extension and varjolintu/keepassxc-proxy-rust - i.e. it appears to be solvable by incorporating some changes. For now this limitation can be circumvented by using KeePassXC's "Automatically launch KeePassXC at system startup" and "Minimize instead of app exit" options (optionally combined with "Minimize window at application startup" and "Show a system tray icon"; personally I used these options from the beginning…).

Since keepassxc-proxy's only purpose is to speak with the socket, it's a perfectly safe solution and utilizes full sandboxing for both KeePassXC and Firefox.

Besides, I'm aware that a native messaging portal has been suggested as a permanent, fully functional and "native" (in the sense of "not requiring workarounds") solution. However, it has been three years now and still I didn't find anything about its status. Flatpak matured in the past years and is more commonly used, personally I'm even thinking about whether I want to have native apps on my system. So, I guess this might be a working solution for now that could be implemented in KeePassXC?

Cc: @droidmonkey @rugk

---

Here's the full instructions for others to get this working in the meantime:

# install Firefox and KeePassXC
flatpak install flathub org.mozilla.firefox
flatpak install flathub org.keepassxc.KeePassXC

# create native-messaging-hosts
FLATPAK_FIREFOX_CONFIG="$(realpath ~/.var/app/org.mozilla.firefox/.mozilla)"
mkdir "$FLATPAK_FIREFOX_CONFIG/native-messaging-hosts"
cat > "$FLATPAK_FIREFOX_CONFIG/native-messaging-hosts/org.keepassxc.keepassxc_browser.json" <<EOF
{
    "allowed_extensions": [
        "[email protected]"
    ],
    "description": "KeePassXC integration with native messaging support",
    "name": "org.keepassxc.keepassxc_browser",
    "path": "$FLATPAK_FIREFOX_CONFIG/native-messaging-hosts/keepassxc-proxy",
    "type": "stdio"
}
EOF

# build varjolintu's keepassxc-proxy-rust and copy it to native-messaging-hosts
# you might need to install Cargo first, but can remove it after building the project again
git clone https://github.com/varjolintu/keepassxc-proxy-rust.git
cd keepassxc-proxy-rust
cargo build --release
cp ./target/release/keepassxc-proxy "$FLATPAK_FIREFOX_CONFIG/native-messaging-hosts/keepassxc-proxy"

# allow the Firefox sandbox to access KeePassXC's browser socket
sudo flatpak override --filesystem=xdg-run/app/org.keepassxc.KeePassXC/org.keepassxc.KeePassXC.BrowserServer org.mozilla.firefox

[droidmonkey]

Placing the proxy within another apps sandbox is not a solution we endorse. It may work but that is definitely not something we will implement.

[PhrozenByte]

Placing the proxy within another apps sandbox is not a solution we endorse. It may work but that is definitely not something we will implement.

What is the reason for that? The proxy doesn't implement any logic on its own, but just connects the application (Firefox) with KeePassXC running in another sandbox. Can you please elaborate on possible security implications and/or other general disadvantages of this solution, especially in comparison with (1) the currently endorsed non-sandboxed approach (i.e. both KeePassXC, or at least Firefox running on the host), and (2) a native messaging portal? Since (1) doesn't include any sandboxing or sandboxing that matters (running KeePassXC in a sandbox protects the host from KeePassXC, not KeePassXC from Firefox) I'd say it causes an overall lower security than the suggested solution?