Fedora Flatpak browser integration is broken (e.g. Silverblue 41)

[nebulon42]

Risking that this has been asked several times already (I did search for similar topics), but I'm stuck and need some advice on how to proceed. I recently switched to Fedora Silverblue 41 and had been using Ubuntu and Pop! OS before where KeePassXC worked very well (thank you). Mentioning this because I'm still a bit unfamiliar with that new system base.

Given that Silverblue is immutable I'm running almost everything as Flatpak and KeePassXC is no exception. It is important to note though that Firefox 133 on my system is not a Flatpak but ships with the base system.

When trying to connect via the Addon I get the "Key exchange was not successful" message. I read the troubleshooting guide. The native-messaging JSON exists and seems to be correct. Using strace and looking into the journal I see that there is the message "Another instance of KeePassXC is already running.". I found a discussion from a few years ago about the same problem stating that the Flatpak was "broken" and was not maintained by this project. This seems to have changed if I have seen this correctly?

I have excluded the possibility that this has something to do with SELinux + Firefox. I temporarily switched off SELinux but the problem was the same.

Do you have any hints on what causes this another instance running message (if that is even the problem) and what else I could try to look for? Maybe there are also some more things in the Troubleshooting guide I have overlooked but at least it does not seem to specifically cover KeePassXC running in a Flatpak.

[droidmonkey]

Another instance of KeePassXC is already running.

This indicates Firefox isn't sending the expected command line parameters so that we start the proxy executable instead of the main application. Flatpak relies on a wrapper script that decides what to start based on the parameters.

This can happen if Firefox has a bug, silverblue is stripping the call, or something else entirely is happening. This could also be caused by apparmor or fire jail on Firefox side.

[nebulon42]

Thanks, that pointed me in the right direction. In strace I see the following:

[pid 30675] execve("/var/lib/flatpak/exports/bin/org.keepassxc.KeePassXC", ["/var/lib/flatpak/exports/bin/org.keepassxc.KeePassXC", "/var/home/user/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json", "[email protected]"], 0x7effe1aa1100 /* 76 vars */ <unfinished ...>

According to what is in the wrapper script this then should start the proxy.

I then executed flatpak run --command=bash org.keepassxc.KeePassXC and had a look into /app/bin but there was no keepassxc-wrapper as defined in the Flatpak manifest. I then double-checked and I had installed the Flatpak from registry.fedoraproject.org instead of from Flathub because this was the default (further reading on the differences between Fedora Flatpaks and Flathub Flatpaks). I then uninstalled and installed from Flathub instead.

After that the wrapper script was present and also the connection from the browser extension worked. So it seems that the Fedora version of the KeePassXC Flatpak is broken. I will figure out how to report this to the Fedora project. Likely this also affects other Fedora projects like Workstation if the Flatpak version from their repository is used.

[nebulon42]

Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2334647 (my ticket, now duplicate)

[droidmonkey]

Oh wow, I didn't know Fedora hosted flatpaks, too. They must have the original version up there. I'd opt for it to just be removed or replaced with a mirror of flathub.

After reading the article, I am very skeptical of their conversion of RPM to flatpak. That only works in the simplest apps, especially if they are applying any level of permissions management. It also misses much needed launcher wrappers because flatpak does not allow multiple binary definitions.

[droidmonkey]

I think this is the source repository for the RPM Flatpak: https://src.fedoraproject.org/flatpaks/keepassxc/blob/stable/f/container.yaml

[nebulon42]

Not sure if the article is still up-to-date, but yes, I was surprised too. I had seen the different remote but didn't pay much attention to it.