1621763 - [flatpak] Support native messaging

Status: RESOLVED DUPLICATE of bug 1955255

(Core :: Widget: Gtk, enhancement, P3)

Description

[Johannes Rohr]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0

Steps to reproduce:

I was trying to connect the flatpak firefox build with KeePassXC using the KeePassXC Browser addon

Actual results:

connection fails. The debugger reveals that no native message support is available, which the add-on requires, see https://github.com/keepassxreboot/keepassxc-browser/issues/804

This is the debugging output:

Error 5: Die Verbindung zu KeePassXC ist nicht möglich. Überprüfen Sie, ob die Browser-Integration in den KeePassXC-Einstellungen aktiviert ist. (no connection with KeePassxc. Please verify whether browser integration is activated in the KeePassXC settings) keepass.js:1062:13
Connecting to native messaging host org.keepassxc.keepassxc_browser keepass.js:979:13
Failed to connect: Unknown error keepass.js:949:13
Error: No content script available for this tab. keepass.js:1180:25
Error 9: Schlüsselaustausch war nicht erfolgreich. (Key exchange failed) keepass.js:1062:13

Expected results:

The KeePassXC browser addon should have connected Firefox with the KeePassXC password manager.

I understand that Native messaging may be conceptually incompatible with Flatpak and that a fix would involve changes to xdg-desktop-portal, see #1591387#c36 so there is probably no quick fix, but I thought it should at least be noted since Flatpak and Snap are growing in importance.

Comment 1

[Johannes Rohr]

OK, here are the relevant links again (which didn't get rendered as expected above)

https://bugzilla.mozilla.org/show_bug.cgi?id=1591387#c36

and

https://github.com/flatpak/xdg-desktop-portal/issues/283

Comment 2

[Erin Yuki Schlarb [:ntninja]]

Being well acquainted with both native messaging and portals I wrote an analysis of the situation over at 1591387. I'm cross-posting this here, for easy reference.

(In reply to ntninja from comment #36)

(In reply to Johannes Rohr from comment #33)

It is great that a flatpak is now available. As a matter of design, it seems to be lacking native messaging support just as the snap package is. Is there any way to fix this? Because without native message, KeePassxc Browser and other add-ons that need it don't work.

Unfortunately the way native messaging hosts are currently designed is conceptually incompatible with the way (Flatpak's) sandboxes work:

• Discovery: Firefox expects foreign applications to place manifest files its own data directory (~/.mozilla/native-messaging-hosts to be exact). This is incompatible with what the sandbox restrictions are supposed to do, but an easy workaround would be designate a new shared directory that all interested applications would request access to and write their manifests there. Only downside would be that different applications could then mess up each others native-messaging files, but as a quick measure it would do.
• Interaction: This is were things get really bad. The native messaging manifests contain a path to a program that Firefox should execute, with the implicit assumption that all applications share the same process and filesystem environments. Since each application runs in its own sandbox however, that assumption is no longer true. Apps could start placing binaries into shared folders, but then those binaries would have to be run inside Firefox's sandbox (thereby completely subverting all sandbox security guarantees) and they would have to have complete access to everything they provide to the Firefox extension from the Firefox sandbox (thereby requiring them to basically be dummy scripts that just forward whatever they receive to some other API on their parent application that does proper permissioning, duplicating that work between every application offering services)

In short: To properly support this we need a discovery/broker mechanism inside xdg-desktop-portal so that apps can advertise support for native-messaging and a D-Bus protocol to replace the current JSON/stdio based communication interface. Support for this needs be part of Firefox, xdg-desktop-portal and every interested app unfortunately. (Using D-Bus service activation and bus enumeration, support xdg-desktop-portal could in theory be skipped, but its probably better to solve this properly once, rather than cooking up a half-baked solution.)

Comment 3

[Pablo]

Since this is an enhancement for linux not really sure where it belongs. I will set component to widget:GTK

Comment 4

[Vincent Bernat]

An alternative would be to gives extensions the ability to talk to a local socket instead of spawning a program. These sockets could be restricted to some specific directory which would be allowed to be exported from host to container by Flatpak. Maybe this could be even transparent for the extension since talking over a socket or over stdin/stdout is quite similar.

Comment 5

[wsha.code]

Based on https://bugzilla.mozilla.org/show_bug.cgi?id=1278719#c47, I think this ticket should be filed under Product="Release Engineering", Component="Release Automation: Flatpak".

I noticed the problem with native messaging support when I saw that the KDE Plasma/Browser Integration extension did not work with the Firefox flatpak.

First off, here is an insecure workaround you can use if you don't care too much about keeping Firefox sandboxed:

1. Copy the native application's app manifest file from /usr/lib64/mozilla/native-messaging-hosts/<app-id>.json to ~/.var/app/org.mozilla.org/.mozilla/native-messaging-hosts/<app-id>.json
2. Create a new file in ~/.var/app/org.mozilla.org/.mozilla/native-messaging-hosts with name like <app-id>.sh and mark it as executable. Make its first line be #!/bin/bash and its second be flatpak-spawn --host <path> "$@" where <path> is the "path" entry in the app manifest json file that was copied.
3. Edit ~/.var/app/org.mozilla.org/.mozilla/native-messaging-hosts/<app-id>.json to change the "path" entry to be the absolute path to the .sh file created in step #2.
4. Start the Firefox flatpak with flatpak run --talk-name=org.freedesktop.Flatpak. If you want, you can run flatpak override --talk-name=org.freedesktop.Flatpak org.mozilla.firefox to make this a default permission for the flatpak so you don't need to specify it each time the flatpak is run.

This workaround is not good for sandboxing because it allows Firefox to call flatpak-spawn to run arbitrary commands on the host. Obviously, a better solution would be preferred. If you are mainly using the Firefox flatpak as a convenient way to install and maintain Firefox, it might be sufficient. Also, Firefox should restrict the WebExtension to running the script that calls flatpak-spawn with specific native command you gave it. The concern is that a bug in Firefox might allow arbitrary flatpak-spawn commands to be run (I think).

The portal discovery idea and the socket communication suggestions seem promising for providing a more secure way of supporting native messaging from the Firefox flatpak. Another method I was wondering about was using Flatpak Extensions. I am not that familiar with how they work exactly but I think they act as a kind of overlay onto the flatpak the way that the app flatpak overlays the runtime flatpak. My thought was that perhaps the native messaging host application could be packaged into an extension and optionally installed on top of the Firefox flatpak. I think this might work well for something like the KDE Plasma/Browser integration because the native messaging app is just a small program that needs a dbus permission to talk to for its functionality. Perhaps other native messaging hosts do not fit this model.

One other thing I thought was interesting was that the Zotero WebExtension worked fine with both Zotero and Firefox as flatpaks. The reason for this is that the Zotero application runs an http server and the Zotero WebExtension communicates with that server via http. Since both flatpaks have the network permission, the WebExtension was able to communicate with the application just as it normally does.

Comment 6

[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.

Comment 7

[marcboocha]

An ipc communication be an alternative for some extensions instead of spawning an application and run stdio. Keepassxc-proxy is a sort proxy to a socket for example and the proxy code could be implemented in the extension it self. That cover some use cases.

For native integration extensions like KDE Plasma Browser integration, it maybe sensible to talk to freedesktop to have a standard way doing some of this functionality.

Comment 8

[Olivier Tilloy]

Snap counterpart: bug 1661935.

Comment 9

[Darkspirit]

S2 (Serious) Major functionality/product severely impaired and a satisfactory workaround does not exist

Comment 10

[Olivier Tilloy]

Proposal for a new NativeMessaging portal to address this issue: https://github.com/flatpak/xdg-desktop-portal/issues/655.

Comment 14

[Agno]

I cannot manage gnome extensions at https://extensions.gnome.org. Is it related to this issue?

Comment 15

[rugk]

Yes, its the same issue

Comment 16

[:gerard-majax]

We should just mark that as a dupe of bug 1661935 i guess

Comment 17

[:gerard-majax]

Enabling on Flatpak will require a bit more work and especially bug 1928096 that :robwu would like to see fixed before we change the pref to enable the auto detection. Also PR https://github.com/flatpak/xdg-desktop-portal/pull/705 is not yet merged, I am unsure of the state of distribution wrt that. Ubuntu for sure has the portal since they need it for Snap usage, but for the others, I'm unclear.

I'll reopen that to make it more clear.

Comment 18

[:gerard-majax]

Assigned by mistake