[snap] chrome-gnome-shell extension fails to detect native host connector

stracing the snap reveals that /usr/bin/chrome-gnome-shell cannot be found in the context of the snap:

  15760 access("/usr/bin/chrome-gnome-shell", F_OK) = -1 ENOENT (No such file or directory)

This is not an apparmor denial. Inside the snap’s execution environment, /usr/bin is in fact /snap/core/current/usr/bin.

Similar report for the Plasma/Browser Integration (https://community.kde.org/Plasma/Browser_Integration): https://forum.snapcraft.io/t/call-for-testing-chromium-62-0-3202-62/2569/65.

Is there any news about this bug?
To this day I still can't use plasma-browser-integration

I've toyed with an unpacked example extension that talks to a native host connector (a simple python script that listens to messages and echoes all it receives).

This works with the following caveats:

 - the connector has to be installed under $SNAP_USER_DATA/.config/chromium/NativeMessagingHosts/

 - the path to the connector in the manifest needs to be an absolute path (as documented at https://developers.chrome.com/extensions/nativeMessaging), e.g.:
    "path": "/home/osomon/snap/chromium/current/.config/chromium/NativeMessagingHosts/native-messaging-example-host"

chrome-gnome-shell wouldn't work like that unmodified, because the connector has external dependencies (it's a python3 script that imports GLib and Gio).

Also, the connector talks to the org.gnome.Shell.Extensions D-Bus API, for which there doesn't exist a snapd interface, so one would need to be written, and I'm pretty sure it wouldn't qualify for auto-connection given the level of privilege it would expose (listing installed extensions, install and uninstall extensions).

This is really frustrating and 19.10 is coming up fast which I understand will switch everyone over to snap based chromium making extensions.gnome.org unusable for everyone. Any chance of switching back to non-snap based chromium if this issue isn't resolved before then?

Unlikely. There are a number of higher priority issues with the chromium snap that we're focusing on now, and the plan to transition from the deb to the snap in 19.10 still holds.

I know this isn't a proper fix, merely a workaround, but you can use gnome-tweaks to manage your gnome-shell extensions.

How and why that snap has been rolled out in 19.10 while we have less feature with it ?

Note: I don't like snap.
This bug is another example why. Moreover nobody cares to fix this. If it is even possible...

zebul666, please take time to read:

https://discourse.ubuntu.com/t/intent-to-provide-chromium-as-a-snap-only/5987
https://discourse.ubuntu.com/t/please-test-chromium-snap-as-a-replacement-for-the-deb/7978
https://discourse.ubuntu.com/t/call-for-testing-chromium-browser-deb-to-snap-transition/11179

Those threads should answer your questions as to why the Chromium browser will only be provided as a snap in Ubuntu 19.10 and eventually in all supported releases of Ubuntu.

This bug is still present in Kubuntu 19.10. Poor Chromium...

Chromium is now incapable of managing extensions for Ubuntu's primary desktop environment? This issue is tolerable only because Google Chrome is not affected. Is Google somehow behind this apparent reluctance to remedy the problem?

It's been reported that the GooPG extension doesn't work because it uses native messaging (https://discourse.ubuntu.com/t/call-for-testing-chromium-browser-deb-to-snap-transition/11179/207).

And from duplicate bug #1853835, the KeePassXC-Browser extension (https://chrome.google.com/webstore/detail/keepassxc-browser/oboonakemofpalcgghocfoadofidjkkk) doesn't work for the same reason: https://github.com/keepassxreboot/keepassxc-browser/issues/405.

2020-01-06 : https://forum.ubuntu-fr.org/viewtopic.php?pid=22202596#p22202596

It seems still broken in not-yet-released ubuntu 20.04.

KDE Connect is also affected by this. I'm wondering though, unable to find the answer online, why was the transition to snap-based chromium made?

(I think) It makes development easier, you don't have to build it for every Ubuntu version in support, or any Linux OS, it contains specific libraries you know won't cause issues with the app.

I want to add this affects Firefox + the KeepassXC extension too. I agree that NativeMessaging is kind of a crutch, but if there is no way to make this work safely a snap interface needs to be implemented that applications from inside / outside of snap can use. There is demand for this kind of interface, so maybe devising a "correct" way of doing this and communicating it to the application / plugin developers would be a good thing...
At the moment I work around by installing firefox from repo and ignore the issue, but some day this might not work anymore. I'm kind of worried that I upgrade to Ubuntu 20.04 and Firefox is not available from repo anymore :/

Hi! Any update on this please? This is an extremely frustrating issue that makes me consider switching from Ubuntu to something else.

This is still an issue on 20.04

This also affects the browserpass extension for the pass (passwordstore.org) password manager

Status changed to 'Confirmed' because the bug affects multiple users.

@osomon, could you point me to an existing forum post or start a new one summarizing what accesses would be necessary to manage gnome shell extensions? I couldn't find one searching, but if there's not one we should open one to try and discuss with snapd architects. Thanks

@anonymouse67: see comments #2, #5, #6 and #7 in this bug.

This "connector" issue is also presents on firefox snap v77.0b2 (64-bit) Ubuntu 20.04 and has not addressed yet.

Harrumph: not impressed. Was working fine this morning, then an update landed me with the snap version.

Back to gnome-tweaks...

Nope, never mind gnome-tweaks. Removed Chromium snap and installed Google Chrome. Problem goes away.

Any changes on this bug (since 2018)? Maybe at least workaround?

I confirm same problem on Focal 20.04 LTS with snap Opera (chrome based)

Download firefox from its website, just run it from it's unzipped directory

One suggestion discussed in https://forum.snapcraft.io/t/allow-classic-confinement-for-postman-agent/19228 is to use a content interface to allow third-party snaps to write to ~/snap/chromium/common/chromium/NativeMessagingHosts/. Whether it’s a good idea from a security perspective is open for discussion, and it wouldn't solve all the problems discussed here, but it could be part of the solution to enable third-party native host connectors.

Hi team, is there any news about this 3y old bug? It would be nice to know if it is something that will be worked on or not even if the timeline indicates towards not.

Although GNOME Shell integration extension is running, native host connector is not detected. Refer documentation for instructions about installing connector.

For Ubuntu 20.04, I have also noticed that both snap installed Chromium and Brave Web browsers fails to work with the gnome-shell-integration extension.

In the case of Brave, this issue can be overcome by following their instruction on installing the .deb versions of brave-browser and brave-keyring files.
$ sudo apt install apt-transport-https curl
$ sudo curl -fsSLo /usr/share/keyrings/brave-browser-archive-keyring.gpg https://brave-browser-apt-release.s3.brave.com/brave-browser-archive-keyring.gpg
$ echo "deb [signed-by=/usr/share/keyrings/brave-browser-archive-keyring.gpg arch=amd64] https://brave-browser-apt-release.s3.brave.com/ stable main"|sudo tee /etc/apt/sources.list.d/brave-browser-release.list
$ sudo apt update
$ sudo apt install brave-browser

However, the chromium-browser does not have a .deb version to fix this issue. If one does issue the command:
sudo apt install chromium-browser,
this command will instead instruct snap to install chromium.

Hope the Chromium developer community can fix this issue given it was first reported in 2018-01-03. Chroumium adoption would be made easier too. Thank you.

I want to make this a bit more clear:

Every single Belgian needs this functionality in order to do basic stuff like:

* File their taxes
* Read communication from the government
* Check their medical history
* Register for a (covid) vaccine
* Rent stuff from the government
* etc.

It is vital that this issue is fixed before phasing out the Firefox deb package. With the Chromium apt package gone, there will be no alternative in the Ubuntu repositories to do these basic things in Belgium.

It’s really nice that our government is supporting Ubuntu using open-source software (https://github.com/Fedict/eid-mw) using common standards and APIs. Breaking this vital functionality looks like a big middle-finger to them.

Thanks for these useful data points Merlijn. That is certainly an important use case that we want to continue supporting. I had a quick look at both the github repository and the "Belgium eID" firefox extension (https://addons.mozilla.org/en-US/firefox/addon/belgium-eid/), and I can't find any references to nativeMessaging there. Am I missing another piece of the puzzle? Or could it be that this is a different problem altogether?

And for future reference, here is Mozilla's documentation on native messaging: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging.

I'm quoting James Henstridge on a possible approach to tackle the problem:

« The design of the native messaging system for extensions is something that could theoretically fit into a confinement system like snapd or flatpak. Instead of executing the native messaging server directly, the browser could ask something outside the sandbox to execute the server and hand it the communication pipes.

That's quite a large project though: it'd require modifications to the browser(s), design and implementation of an API (maybe in xdg-desktop-portal?), evaluation of the security implications, etc. »

> there will be no alternative in the Ubuntu repositories to do these basic things in Belgium.

using epiphany (the GNOME browser) should work no?

Discussion to figure out a solution is continuing at https://forum.snapcraft.io/t/native-messaging-support-in-strictly-confined-browser-snaps/26849. Please refrain from "me too" or "+1"-like comments (but valid use cases that weren't mentioned yet or suggestions are welcome).

It seems, Belgium eID (Comment #36) uses PKCS#11, not native messaging:
https://github.com/Fedict/eid-mw/blob/master/plugins_tools/xpi/new-src/manifest.json
However the problem is essentially the same: native manifest.
Olivier filed a bug in Firefox bugzilla:
https://bugzilla.mozilla.org/1734371
"Firefox snap can't load PKCS#11 modules on the host system"

I suppose, the title of this bug does not reflect scale of the problem.
All browser add-ons that relies on native manifests are affected
in Chromium and Firefox.

I came across this issue testing an extension in Firefox using Ubuntu-21.10
live image. I am considering whether it is feasible to run a kind of thin
proxy server on host that creates a socket inside a directory mounted to snap
and runs a binary in response to connection (something like inetd).
It requires a stub for native messaging app that connects to the server
and pass through requests and responses. Generally it does not differ
too much from D-Bus and ideally requires support from Firefox for robust
checks if particular add-on is allowed to run a specific app.

It seems 1Password is also affected for this bug. I don't understand what happens behind, but 1Password also fails to communicate with Firefox Snap. My original bug report: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1964546

This bug is still there with 22.04 installed this morning. As I can't install the deb package anymore this is really annoying.

I can confirm that this issue is still present in Ubuntu 22.04. Extensions can only be installed manually now.

[Workaround]
Use Extension manager to install gnome extensions
https://flathub.org/apps/details/com.mattjakeman.ExtensionManager

Status changed to 'Confirmed' because the bug affects multiple users.

Same issue here with KeepassXC native transport on Ubuntu 22.04 and firefox. Worked flawless on 20.04.

Similar problems exist with for example expressVPN (which recommends to uninstall the snap version and install a ppa-version of firefox instead: https://www.expressvpn.com/de/support/vpn-setup/app-for-linux/#software-center) and with the video-download-helper extension (https://www.downloadhelper.net/).

Same thing: native manifest.

See also here: https://forum.snapcraft.io/t/firefox-from-ubuntu-snap-store-doesnt-support-download-helper/5663

Is this scheduled to be fixed soon? My apologies if this may not be the right bug but I use Firefox and cannot log into the Zoom app behind a SSO login (as it must go to zoom.us). Firefox already has safeguards about "are you sure you want to open this" and asks twice. It worked fine in KUbuntu 21.10 but 22.04 is broken and I cannot log in. This is a workflow stopper.

@paulstejskal I don't think the issue you are describing is caused by the bug described in this bug report. You might need to file a separate bug report or ask for help elsewhere.

@paulstejskal Do you use the Zoom Snap? Please look here: https://github.com/ogra1/zoom-snap/issues/111

Still no solution for the Belgian eid card!!! There is only one way out as it is serious: Cange to Linux Mint which is withou snap or Zorin. That's what I did. What else could I do? Have a nice day all of you.

Got it friends. Follow the way: Synaptic + gdebi (install) Get to the "www.myminfin.be" Download the eID-software. Back to gdebi to install the software. Then "sudo apt update" After that back to Synaptic to install them all: beid-mozilla-extension beid-mozilla- webext eid-archive eid-mw eid viewer libeidpkcs 11-0 libeidpkcs 11-bin libeidviewer 0 That's all folks.

If the driver of the eid-viewer doesn't work: "sudo systemctl enable pcscd" and then "sudo systemctl start pcscd.

Good luck! The launcher will be ready.

One can use the builds directly from Mozilla https://www.mozilla.org/firefox/all/ but the onus is on the user/sysadmin to keep it updated.

Plasma Browser integration now kind of works with:

firefox 106.0.5-1 2067 latest/stable/… mozilla✓
xdg-desktop-portal 1.14.4-1ubuntu2~22.04.1

but I had to manually set permission - following directions for KeePassXC integration.

Steps:

sudo apt-get install flatpak
flatpak permission-set webextensions org.kde.plasma.browser_integration snap.firefox yes
restart firefox

@lucas+- The onus is now on the user/sysadmin as well, because of the annoying update notifications of the firefox snap and the blocking of "snap refresh firefox" by a running firefox (why do I have to do this manually).
If this would be fixed, the firefox snap will finally be worthy of inclusion into a LTS version!
IMHO, this process is what interim releases are for and I just don't get, why Canonical and Mozilla decided that they want to torture LTS users with this UX.

@slalomsk8er, I'm not disagreeing with snap's shortcomings, I'm just providing alternatives for anyone who's run into such issues. There is now also the option of getting stable builds in .deb form from the MozillaTeam (https://wiki.ubuntu.com/MozillaTeam) PPA at
https://launchpad.net/~mozillateam/+archive/ubuntu/ppa
There are many guides about how best to use it and ensure you receive automatic updates.

They have been providing ESR builds for some time, but recently added stable packages. I haven't found any info that verifies their members as employed by either Canonical or Mozilla, but they seem to have some trust by the community.