1942175 - Provide KeePassXC flatpak extension for Firefox flatpak build to allow interoperability with KeePassXC desktop application

Status: UNCONFIRMED

(Firefox Build System :: Third Party Packaging, defect)

Description

[rugk]

Steps to reproduce:

1. Install the official Firefox flatpak for Linux: https://flathub.org/apps/details/org.mozilla.firefox
2. Install KeePassXC desktop application.
3. Install the KeePassXC browser extension (add-on/WebExtension)

Unfortunately, the real https://github.com/flatpak/xdg-desktop-portal/pull/705

Actual results:

4. Now try to connect -> it will not work due to flatpak sandboxing.

This is a well-known and expected problem, after all. See https://unix.stackexchange.com/q/584521/146739 for example.

Expected results:

Now, my proposed solution is based on this idea:
https://github.com/keepassxreboot/keepassxc/issues/7352#issuecomment-2409096972

Apparently, you can solve it by two simple steps:

1. keepasxc-proxy binary to Firefox's sandbox
2. Allowing Firefox to access the socket of KeePassXC which is just flatpak override --filesystem=xdg-run/app/org.keepassxc.KeePassXC/org.keepassxc.KeePassXC.BrowserServer org.mozilla.firefox

This now can be shipped by a thing called flatpak extensions (which work like plugins), because flatpak supports this: https://docs.flatpak.org/en/latest/extension.html

So the setup whole step would become:

1. Install the official Firefox flatpak for Linux: https://flathub.org/apps/details/org.mozilla.firefox
2. Install KeePassXC desktop application.
3. Install the KeePassXC browser extension (add-on/WebExtension)
4. New: (at any point of time) Install the flatpak extension for KeePassXC.

IMHO, this would be a very big achievement and improvement already. I mean especially if it is compared against the thing "not working at all".
And as alternative solutions are not there yet, maybe this is a good idea?

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[rugk]

Also proposed on https://discourse.flathub.org/t/pitch-idea-firefox-flatpak-extension-to-run-keepassxc/8673

Also the sentence above should read *Unfortunately, the real solution is still waiting.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mkaply, could you have a look please?

For more information, please visit BugBot documentation.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:gerard-majax, could you have a look please?

For more information, please visit BugBot documentation.

Comment 5

[:gerard-majax]

(In reply to rugk from comment #0)

Steps to reproduce:

1. Install the official Firefox flatpak for Linux: https://flathub.org/apps/details/org.mozilla.firefox
2. Install KeePassXC desktop application.
3. Install the KeePassXC browser extension (add-on/WebExtension)

Unfortunately, the real https://github.com/flatpak/xdg-desktop-portal/pull/705

Actual results:

4. Now try to connect -> it will not work due to flatpak sandboxing.

This is a well-known and expected problem, after all. See https://unix.stackexchange.com/q/584521/146739 for example.

Expected results:

Now, my proposed solution is based on this idea:
https://github.com/keepassxreboot/keepassxc/issues/7352#issuecomment-2409096972

Apparently, you can solve it by two simple steps:

1. keepasxc-proxy binary to Firefox's sandbox
2. Allowing Firefox to access the socket of KeePassXC which is just flatpak override --filesystem=xdg-run/app/org.keepassxc.KeePassXC/org.keepassxc.KeePassXC.BrowserServer org.mozilla.firefox

This now can be shipped by a thing called flatpak extensions (which work like plugins), because flatpak supports this: https://docs.flatpak.org/en/latest/extension.html

So the setup whole step would become:

1. Install the official Firefox flatpak for Linux: https://flathub.org/apps/details/org.mozilla.firefox
2. Install KeePassXC desktop application.
3. Install the KeePassXC browser extension (add-on/WebExtension)
4. New: (at any point of time) Install the flatpak extension for KeePassXC.

IMHO, this would be a very big achievement and improvement already. I mean especially if it is compared against the thing "not working at all".
And as alternative solutions are not there yet, maybe this is a good idea?

There's no need for hacks, the correct fix is:

• merge https://github.com/flatpak/xdg-desktop-portal/pull/705, but we are not in charge of that, and I regularly ping people for that
• distro to release the version including this
• flip the pref on our side which is blocked by https://bugzilla.mozilla.org/show_bug.cgi?id=1928096

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:gerard-majax, could you have a look please?

For more information, please visit BugBot documentation.

Comment 7

[:gerard-majax]

Sebastian, do you know when this can move forward?

Comment 8

[:gerard-majax]

Have you opened an upstream bug against your distro to maybe include the PR as a patch on their package ? This would at least allow you to toggle the pref and make use of Native Messaging from the Flatpak

Comment 9

[rugk]

It makes no sense to ask a distro downstream, because they hardly use flatpak respectively this request was for the "official" Mozilla flatpak (on flathub).

But if you want to wait for the "real" xdk-desktop/portal integration being finished, then fine. The ticket was just opened precisely, because this does not seem to come forward.

Comment 10

[:PhrozenByte]

:gerard-majax, I agree that the proper fix of this would be that the Flatpak people finally merge https://github.com/flatpak/xdg-desktop-portal/pull/705. However, it has been three years now. Do you believe that this is going to happen any time soon?

:rugk now basically suggests to no longer wait for https://github.com/flatpak/xdg-desktop-portal/pull/705 and to bypass the Flatpak portal approach for now. The idea is based on a workaround for KeePassXC I summarized (but didn't originally create) at https://github.com/keepassxreboot/keepassxc/issues/7352#issuecomment-2409096972. However, this workaround can't really solve Native Messaging, but only parts of it: The IPC part of Native Messaging to be more precise.

The idea of native messaging is to allow browser extensions to start other processes and exchange information with them. For standalone desktop applications like KeePassXC this parent-child approach isn't really feasible. Thus they created a small proxy application whose only job is to act as intermediary: KeePassXC creates a BSD socket in a well-known runtime directory and Firefox launches the small proxy process that basically just connects to that BSD socket, establishing a communication channel between Firefox (resp. the KeePassXC browser extension) and KeePassXC. I presume that many Native Messaging users have similar approaches.

Flatpak doesn't really interfere here: If one adds this small proxy application to Firefox's Flatpak and if the Firefox Flatpak has access to the same well-known runtime directory, Firefox and KeePassXC can communicate. That's basically what I've described in the KeePassXC GitHub issue linked above. However, as you've probably already noticed, there's a catch: Without containerization that small proxy application can also start KeePassXC if it isn't running already. With Flatpak it can't. Thus it really just allows communication with already running applications and is therefore just a partial solution for Native Messaging.

:rugk now suggests creating Flatpak extensions that ship these small proxy applications and request access to their respective runtime directory. I don't think that we really need these Flatpak extensions: We could also add a new Native Messaging type "socket" that allows Firefox to directly connect to existing BSD sockets.

There's one major security consideration though: Since this would require well-known paths, malicious applications could easily intercept the communication and do bad things - in both directions, i.e. a browser extension escaping from Firefox's container, and other (possibly containerized) applications breaking into Firefox's container. The applications and browser extensions must be aware of this issue and implement counter-measures. So, we'd definitely need an allowlist...

On a side note: I personally wouldn't fully dismiss the "nuclear option" by proposing distros to patch that PR into their packages. In the end this comes down to the reasons why this hasn't been merged for three years now - and quite frankly, I see some parallels to the latest "Rust for Linux" discussion...

Comment 11

[:gerard-majax]

Please avoid speculations: the history on the PR is enough to know. Current code is ready, I spoke with sebastian at FOSDEM and the final landing is just a matter of the people to do it, there is no blockage as much as I understand it, just shortage of resources. You need to also consider the code took time to bake and mature, including on the firefox side.

People who are interested can also see why we have not yet togggled the pref by default, because it lacks test coverage that is being done in https://bugzilla.mozilla.org/show_bug.cgi?id=1928096

If there's a right course of action here, it's really for distro to pick the PR and apply it.

Comment 12

[:gerard-majax]

(In reply to :PhrozenByte from comment #10)

:gerard-majax, I agree that the proper fix of this would be that the Flatpak people finally merge https://github.com/flatpak/xdg-desktop-portal/pull/705. However, it has been three years now. Do you believe that this is going to happen any time soon?

There was extensive design and documentation discussions that were blocking bug 1661935 but it all got resolved a few weeks ago and we could finally land it on our side, so it is just taking a bit more time on their side.