Use single extension point for extensions, policies and native messaging hosts?

[gasinvein]

It's fairly common that a vendor wants to ship several objects of these 3 kinds at once, which may be interdependent. For example, in Fedora the package fedora-chromium-config contains an extension and a policy. Things like KeePassXC and Plasma Browser Integration consist of an extension and a native messaging host.
Currently, it's not possible to ship different kinds of such extensions in one bundle. Using single extension point with merge-dirs set to native-messaging-hosts;extensions;policies/managed;policies/recommended would solve this.

[andrunko]

I wouldn't mind to change the extension points to support all dirs or maybe come up with a new extension point for that, but we should avoid changing the existing ones on a backwards incompatible way as that would break existing users which expect the current structure.

Fwiw, there is nothing blocking packages to ship multiple extension points (extension + policy) in the same underlying package (e.g. for unmanaged extensions, as we do on Endless OS)

[gasinvein]

Do you know of any other real-world usage of the extension points except EndlessOS?

there is nothing blocking packages to ship multiple extension points (extension + policy) in the same underlying package

This is possible for unmanaged extensions, but not for native flatpaks. Maintainer has no means to make sure that interdependent extensions are installed simultaneously.

[hammerandtongs]

Native messaging host needs a path to a binary, the directory is just for the json metadata around the connection I believe(?).

Where should that be? Right now ubuntu kde just puts its binary -

/usr/bin/plasma-browser-integration-host

[gasinvein]

@hammerandtongs Binary can be stored in the flatpak extension bundle, alongside json metadata. Doing so for Plasma Browser Integration in particular, though, won't be easy due to dependency on Qt/KDE. Also some flatpak-spawn --host wrapper may be used.
In any case, this is an interesting question, but out of scope of this issue, since my proposal won't change things in this regard.

[andrunko]

Do you know of any other real-world usage of the extension points except EndlessOS?

Not that I know of.

there is nothing blocking packages to ship multiple extension points (extension + policy) in the same underlying package

This is possible for unmanaged extensions, but not for native flatpaks. Maintainer has no means to make sure that interdependent extensions are installed simultaneously.

I think the best to do in this case would be to come up with a new extension point then - would be happy to review if someone comes up with a PR but won't have time to look at this atm I'm afraid.

[gasinvein]

won't have time to look at this atm I'm afraid

NP, this issue is more of a RFE than an actual issue. Just wanted to point out that current layout may potentially pose a problem for flatpak'ing Chromium extensions, if someone decides to do it.

a new extension point

It'll need a new mount point. Would Chromium be able to pick up extension/policy files from multiple directories? E.g. load policy from chromium/policies/policies/managed (current extension) and from, say, chromium/extensions/policies/managed (new extension)?
Also, can we reuse org.chromium.Chromium.Extension extension point for that, just add policies and native messaging hosts to its merge-dirs?

[andrunko]

a new extension point

It'll need a new mount point. Would Chromium be able to pick up extension/policy files from multiple directories? E.g. load policy from chromium/policies/policies/managed (current extension) and from, say, chromium/extensions/policies/managed (new extension)?

I don't see why not, even if the current code only supports one dir we can always change that.

Also, can we reuse org.chromium.Chromium.Extension extension point for that, just add policies and native messaging hosts to its merge-dirs?

Not sure tbh, I would have to try and see.

[refi64]

The source assumes a single directory for these in several places, changing it wouldn't be impossible but would be moderately invasive (and also fun to rebase). That being said, I guess we could also merge some of this by hand in the wrapper script, IIRC the target of merge-dirs is a tmpfs.

Also, can we reuse org.chromium.Chromium.Extension extension point for that, just add policies and native messaging hosts to its merge-dirs ?

I don't entirely understand this suggestion, is it to replace the current, multiple extension points for extensions & native messaging hosts with a single one?

[gasinvein]

is it to replace the current, multiple extension points for extensions & native messaging hosts with a single one?

Well, yes, but not necessarily replace existing ones, just to have such an extension point that could contain everything.

[refi64]

We can't have multiple extensions mounted on one path, since Flatpak mounts a clean tmpfs for each one. That being said, I guess we could introduce a single one, and use some symlink magic in the startup scripts to keep compat with the previous extension points.

[iavael]

Are there any ideas on implementing this change? Currently extension points for NMH and policies are broken and cannot be used (#78). Looks like this change may help.