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

Bug #1741074 reported by Olivier Tilloy
618
This bug affects 122 people
Affects Status Importance Assigned to Milestone
KeePassXC Snap Builds
Unknown
Unknown
Mozilla Firefox
New
Unknown
chromium-browser (Ubuntu)
Medium
Unassigned
firefox (Ubuntu)
High
Olivier Tilloy
goopg (Ubuntu)
Undecided
Unassigned
kdeconnect (Ubuntu)
Undecided
Unassigned

Bug Description

Revision history for this message
Olivier Tilloy (osomon) wrote :
Revision history for this message
Olivier Tilloy (osomon) wrote :

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.

Revision history for this message
Olivier Tilloy (osomon) wrote :
Revision history for this message
Emanuele (emanuc) wrote :

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

Revision history for this message
Olivier Tilloy (osomon) wrote :

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"

Revision history for this message
Olivier Tilloy (osomon) wrote :

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

Revision history for this message
Olivier Tilloy (osomon) wrote :

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

Revision history for this message
Russ Dill (russ-dill) wrote :

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?

Revision history for this message
Olivier Tilloy (osomon) wrote :

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.

Revision history for this message
zebul666 (zebul666) wrote :

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

Revision history for this message
Paul White (paulw2u) wrote :

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.

Revision history for this message
sbaragnaus (sbaragnaus) wrote :

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

Revision history for this message
Proton Pony (protonpony) wrote :

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?

Revision history for this message
Olivier Tilloy (osomon) wrote :

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

Revision history for this message
Olivier Tilloy (osomon) wrote :
Revision history for this message
Coeur Noir (coeur-noir) wrote :

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

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

Revision history for this message
Avamander (avamander) wrote :

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?

Revision history for this message
Efthimios Chaskaris (echaskaris) wrote :

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

Revision history for this message
Horst Baerbel (horstbaerbel) wrote :

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 :/

Revision history for this message
Balazs Gyurak (ba32107) wrote :

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

Revision history for this message
Alberto Donato (ack) wrote :

This is still an issue on 20.04

Revision history for this message
Jeffrey Bouter (jbouter) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in goopg (Ubuntu):
status: New → Confirmed
Changed in kdeconnect (Ubuntu):
status: New → Confirmed
Revision history for this message
Ian Johnson (anonymouse67) wrote :

@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

Revision history for this message
Olivier Tilloy (osomon) wrote :

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

Revision history for this message
Farab (farabf33) wrote :

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

Revision history for this message
Bruce Crowther (bwucie) wrote :

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

Back to gnome-tweaks...

Revision history for this message
Bruce Crowther (bwucie) wrote :

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

Revision history for this message
Marcin (mwoz123) wrote :

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)

Revision history for this message
Efthimios Chaskaris (echaskaris) wrote :

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

Revision history for this message
In , Eduardo Rojas Rodríguez (edurojas) wrote :

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

Steps to reproduce:

Steps to reproduce:

    Use the Firefox Snap build from Ubuntu Snap Store (Ubuntu software).

    Install "chrome-gnome-shell" package.

    Install Firefox GNOME Shell integration.

    Go to "extensions.gnome.org" and choose any extension.

Actual results:

Actual results:

An error report shows that says the native host connector cannot be detected.

There is no option to install the GNOME extension.

Expected results:

Expected results:

I should be able to install the chosen GNOME extension directly from the website and manage it afterwards.

The behavior is correct on the current RPM/DEB builds.

Revision history for this message
In , Release-mgmt-account-bot (release-mgmt-account-bot) wrote :

[Bugbug](https://github.com/mozilla/bugbug/) thinks this bug should belong to this component, but please revert this change in case of error.

Revision history for this message
Olivier Tilloy (osomon) wrote :

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.

Rob David (rob-david)
affects: chromium-browser → keepassxc-snap
affects: keepassxc-snap → keepassxc-browser (Ubuntu)
Rob David (rob-david)
affects: keepassxc-browser (Ubuntu) → keepassxc-snap
Revision history for this message
lerra (lerra82) wrote :

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.

Revision history for this message
udo (udopton) wrote :

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

Revision history for this message
SunBear (sunbear-c22) wrote :

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.

Revision history for this message
Merlijn Sebrechts (merlijn-sebrechts) wrote :

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.

Revision history for this message
Olivier Tilloy (osomon) wrote :

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?

Revision history for this message
Olivier Tilloy (osomon) wrote :

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.

Revision history for this message
Olivier Tilloy (osomon) wrote :

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

using epiphany (the GNOME browser) should work no?

Revision history for this message
Olivier Tilloy (osomon) wrote :

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

Revision history for this message
In , Olivier Tilloy (osomon) wrote :
Olivier Tilloy (osomon)
Changed in firefox (Ubuntu):
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Olivier Tilloy (osomon)
Changed in firefox:
status: Unknown → New
Revision history for this message
In , David D Lowe (flimm) wrote :

This bug is also being tracked at https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1741074

Ubuntu 21.10 ships the snap version of Firefox by default, (instead of the APT version), so we can expect more users to experience this bug.

Revision history for this message
Max (m-gorodok) wrote :

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.

Revision history for this message
In , Olivier Tilloy (osomon) wrote :

Flatpak counterpart: bug 1621763.

Revision history for this message
In , W-jan-k (w-jan-k) wrote :

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

Revision history for this message
In , Olivier Tilloy (osomon) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.