1318461 - Native host manifest location should be arch-independent in Linux

Status: NEW

(WebExtensions :: General, defect, P5)

Description

[Yuri Konotopov]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.100 Safari/537.36

Steps to reproduce:

I placed native host manifest file to /usr/share/mozilla/native-messaging-hosts/<name>.json according to docs: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_messaging#Linux


Actual results:

Native host app is not accessible from webextension


Expected results:

Native host app should be accessible from webextension.

If I place manifest file to /usr/{lib,lib64}/mozilla/native-messaging-hosts/ - it works as expected.
However /usr/{lib,lib64} is not a proper place for platform-independent files like Native app manifests.

According to FHS such files should be placed to /usr/share (or /etc because they may be treated as configuration files).

Also usage of /usr/{lib,lib64} for native manifests may be considered as bad practice while packaging native app for some Linux Distros (like Debian) and rejected.

Comment 1

[Robert Helmer [:rhelmer]]

Would it be a problem for Debian packages in particular if a package stuck a manifest file into /usr/{lib,lib64} as opposed to /usr/share or /etc ?

The use case is that the presence of a manifest allows a WebExtension to invoke and communicate with an external process, placing the manifest is generally the responsibility of the app and not something the user would configure.

We don't want to make it harder for people to support than necessary.

Comment 2

[Mike Hommey [:glandium]]

(In reply to Robert Helmer [:rhelmer] from comment #1)
> Would it be a problem for Debian packages in particular if a package stuck a
> manifest file into /usr/{lib,lib64} as opposed to /usr/share or /etc ?

A JSON file, yes.

Comment 4

[sander.lepik]

Hi!

Is there any progress on this bug? It gets quite annoying and Firefox 52 is nearing.

Comment 5

[Tomislav Jovanovic :zombie]

Can someone explain how big of a problem this is?  The fact that it's against the Debian rules, does that mean it's also a problem on Ubuntu?

Basically, if this is affecting a significant percentage of Linux users, I believe it should be a higher priority, as long as Linux is still a P1 supported platform for Firefox.

Comment 6

[Yuri Konotopov]

1. Current manifest location is against FHS. This reason already should be a "big problem".
We blame Microsoft for making custom, non-standard things (hello, IE < 11), so let's do not make such non-standard architecture step.
2. Any architecture-independent package which ships native host messaging manifest became architecture-dependent.
Instead of providing one "noarch" package we should provide "x86" and "amd64" packages.

Comment 7

[Andrew Swan [:aswan]]

This bug is labeled a P5.  See the descriptions of bug priorities linked below, this means that we aren't aware of anybody currently planning to work on it but that we will accept patches from somebody interested in doing the work.

https://wiki.mozilla.org/Bugmasters/Projects/Folk_Knowledge/Priority_Field#Priority-based_triage

Comment 8

[Yuri Konotopov]

For the last year this caused issues in Linux distros:

Arch: https://aur.archlinux.org/packages/chrome-gnome-shell-git/?comments=all#comment-575628-content
Fedora: https://bugzilla.gnome.org/show_bug.cgi?id=787643
Gentoo: https://bugs.gentoo.org/643522

There is hidden issue in Debian/Ubuntu so it's package will work while built on 32 bit buildhost only.

There are no any problem with Chromium's native manifest location ever because it's arch-independent.

Comment 9

[torhedinbronner]

I'm running into this problem on NixOS, which doesn't use the FHS. Using XDG_DATA_DIRS, falling back to /usr/share/, is probably the sane solution.

Comment 10

[rugk]

This issue has been mentioned in https://github.com/flatpak/xdg-desktop-portal/pull/705#issuecomment-1308723680 as a good thing to be solved for the flatpak/snap WebExtension/native messaging xdg-portal.

Comment 11

[Filip Š]

I think that Firefox on Linux should try to load manifests (and certificates apparently, as they also use the same base directory) from both /usr/lib/mozilla and /usr/lib64/mozilla, regardless of the architecture, so it would also detect native apps from packages that only place manifest into one of this directories. Additionally, it seems Firefox uses /usr/local/lib/mozilla on OpenBSD and FreeBSD (but /usr/lib64/mozilla when lib64 is enabled), so this directory should still be used on BSD (along with the other two directories for consistency on Linux, and maybe /usr/local/lib64/mozilla if that exists).

Additionally, since some distros discourage placing platform-independent files to /usr/lib, Firefox should probably also support loading manifests (and certificates) from /usr/share/mozilla, still in combination with all other existing paths for backward compatibility. This should probably also be a preferred path.

However, I don't know what's the best way of implementing it. The path is currently obtained through XRESysNativeManifests. If these new directories were to be implemented in the same way, this would require at least 3 new such service keys (I don't know what the correct terminology is). An easier (but more "hacky") way would be to just hard-code the new paths (/usr/share/mozilla, /usr/lib/mozilla, /usr/lib64/mozilla, and maybe also /usr/local/lib/mozilla or even /usr/local/lib64/mozilla) where they are used (here and here) on Linux (and BSD). The original service key should probably stay, and Firefox will just continue searching in other directories in the list if it's not found there. This is a lot easier than creating new service keys, but I don't know if it's considered a good practice and could be accepted.

If the implementation with hard-coded directories is good enough, I can probably contribute a patch at some point.