Unable to allow installing a specific signed extension outside of the AMO

[celenityy]

Hey there,

So, I want to block users from installing extensions outside of the AMO... but for example, let's say I want them to be able to install the signed extension: magnolia@12.34, which is unavailable in the AMO.

Relevant policies from my policies.json:

  "ExtensionSettings": {
      "*": {
        "blocked_install_message": "Blocked.",
        "install_sources": [
          "https://addons.mozilla.org/*"
        ],
        "allowed_types": [
          "extension",
          "theme"
        ]
      },
      "magnolia@12.34": {
        "installation_mode": "allowed"
      }
}

Despite these policies being set, when I try to install the extension from its Gitflic Page at the following URL: https://gitflic.ru/project/magnolia1234/bpc_uploads/blob/raw?file=bypass_paywalls_clean-latest.xpi, the installation is still being blocked.

Other examples of this include Mullvad's Browser Extension.

I feel like I'm missing something silly here... but I've read through the docs and I'm not quite sure what.

Any ideas here?

Thank you for your time. :)

[celenityy]

I've done some more testing, and here's where it gets weird:

Instead of creating a separate entry for the extension with the allowed installation_mode, if I rather update the install source, it seems to partially work?

For instance, if I add https://cdn.mullvad.net/browser-extension/* to my install sources, it allows installing Mullvad's browser extension from their website (https://cdn.mullvad.net/browser-extension/latest/).

But, if I add https://gitflic.ru/project/magnolia1234/bpc_uploads/blob/* to my install sources, it still blocks installing the extension?

I'm guessing that I'm either putting the wrong URL here (or doing something else wrong without realizing...) or that this is probably undesired/a bug, due to the inconsistency.

This solution wouldn't be ideal anyways since I'd rather just whitelist the specific extension ID, but would be better than nothing.

[mkaply]

fYI, I've been out. I'll look at this tomorrow.

[mkaply]

It's something about how

https://gitflic.ru/project/magnolia1234/bpc_uploads/blob/raw?file=bypass_paywalls_clean-latest.xpi

is being served by the website.

Even in a browser without policies set, if I go to that URL, it tries to download the XPI, not install it.

It needs to be served with the mime type:

application/x-xpinstall

[mkaply]

Also, because install_sources is checked first, that's why you need to set that value.

We won't try to install an addon with a specific addon ID if it comes from a source that isn't allowed in the first place. I think Chrome behaves the same way.

[celenityy]

fYI, I've been out. I'll look at this tomorrow.

No worries, thanks for your time looking at this :)

For context, I'll try to explain my use case here:

Essentially, I'm trying to limit installing extensions & themes to the AMO for users, with exceptions to allow installing certain extensions outside of the AMO (Ex. Mullvad's, BPC Clean, etc).

I'm trying to avoid setting "installation_mode": "blocked" globally, since for example, I have no problem with my users installing themes (And individually whitelisting every theme is just impossible...). I also generally believe that extensions are important and I don't want to gate-keep them for legitimate uses, I currently just manually block extensions I don't want users to install.

Hopefully this makes sense & I'm curious if there's a better way to accomplish this that I'm missing.

It's something about how

https://gitflic.ru/project/magnolia1234/bpc_uploads/blob/raw?file=bypass_paywalls_clean-latest.xpi

is being served by the website.

Even in a browser without policies set, if I go to that URL, it tries to download the XPI, not install it.

It needs to be served with the mime type:

application/x-xpinstall

Hmm. I should've thought to test without policies, good thinking. Is this something the dev can fix or is it something on gitflic.ru's end? I can probably file an issue with the dev about this if needed. In the meantime, what would you recommend as a solution for my situation?

What's interesting is that directly installing the extension through policies like this works fine:

  "magnolia@12.34": {
    "installation_mode": "normal_installed",
    "install_url": "https://gitflic.ru/project/magnolia1234/bpc_uploads/blob/raw?file=bypass_paywalls_clean-latest.xpi",
    "updates_disabled": false,
    "temporarily_allow_weak_signatures": false
  }

We won't try to install an addon with a specific addon ID if it comes from a source that isn't allowed in the first place. I think Chrome behaves the same way.

Ok, that makes sense. But for my case, if I add the source, since I'm not setting `"installation_mode": "blocked"' globally, wouldn't that allow any add-on from that source to be installed? I think it'd be nice to be able to make exceptions for allowing certain add-ons outside of the AMO without having to trust another source entirely.

I could see this being implemented through the allowed installation_mode if the install_url is specified, ex. maybe something like this?:

  "d19a89b9-76c1-4a61-bcd4-49e8de916403": {
    "installation_mode": "allowed",
    "install_url": "https://cdn.mullvad.net/browser-extension/*"
  }

[mkaply]

I've looked into this and I think using install_sources is really your only option here.

You could set allowed_types to be just themes, but then extensions couldn't be installed from AMO.

As far as the gitflic.ru site goes, I don't know enough about how that site is serving files to know how they can fix it.

The reason it works if you do a normal_installed is because we download the XPI and install it no matter what.

I do agree it would be great if we could allow an explicit ID from anywhere regardless of the source. I'll open a bug to look into this.

[mkaply]

https://bugzilla.mozilla.org/show_bug.cgi?id=1914220

[celenityy]

I've looked into this and I think using install_sources is really your only option here.

Understood. Will stick to that then for the time being.

As far as the gitflic.ru site goes, I don't know enough about how that site is serving files to know how they can fix it.

👍 Makes sense. The extension was previously hosted on GitHub which worked fine, so I'm guessing it is something specifically with how gitflic.ru is serving the files. I'll file an issue with the dev and see what the options are.

I do agree it would be great if we could allow an explicit ID from anywhere regardless of the source. I'll open a bug to look into this.

💯 Please keep me posted.