1771341 - Make sure test harness extensions (like mochikit and specialpowers) are identified as privileged extensions

Status: NEW

(WebExtensions :: General, task, P3)

Description

[Luca Greco [:rpl] [:luca] [:lgreco]]

The "experiments_apis" manifest field is a privileged property and it is expected to be only allowed to extensions that are considered privileged (either because of their privileged signature, for the locations where they are installed, or because installed temporarily and the "extensions.experiments.enabled" pref is set to true).

Unfortunately that assumption isn't currently matched by the extensions that some of our test harnesses depend on (e.g. mochikit, specialpowers are two that all mochitests test harnesses depends on) , which are installed as unsigned and expects to be allowed to use the "experiment_apis" manifest field.

Because of that disallowing all unsigned extensions to use the "experiment_apis" does trigger failures for all tests parts of the test harness as a side effect of that, and so the "experiment_apis" manifest property is currently special cased and allowed more broadly while the browser is running under automation.

We would like to consider alternative approaches to ensure these extensions part of the test harnesses are allowed to use "experiment_apis", possibly by making them to be identified as privileged (instead of the currently way of special casing this corner case).

Comment 1

[Kris Maglione [:kmag]]

The main reason for the special case, rather than signing these extensions as privileged (aside from ease of maintenance), is that we don't actually want these extensions to extensions to work outside of automation. Having SpecialPowers installable in the wild and still working as a privileged extension would be Very Bad. It does have some assertions so it crashes if run outside of automation, but even having it privileged-signed and installable outside of automation would not be desirable.

Comment 2

[Luca Greco [:rpl] [:luca] [:lgreco]]

Thanks a lot Kris, that is really useful context to consider.

Signing those extensions as privileged doesn't definitely sound like a reasonable option, even besides the pretty good reason you mention in comment 1.

A possible alternative approach that I was considering to propose is an "automation-only" location

Basically a location that the AOM would not even look outside of automation (and where the test harness extensions would be expected to be installed to be able to access this privileged feature while running under automation).

It should be explicit enough to be more clearly visible (in terms of making it visible why is that necessary, what is depending on it) and (at least if I'm not mistaken or I'm misreading the context of the current approach described in comment 1) to be still as strict as the current approach (in terms of making it really hard to expose by mistake these powerful/dangerous extensions outside of automation).