You seem to be correct that ESR still allows Extension Signing to be disabled in the usual way. And that's great! (It saves my trying modify the two omni.ja files to achieve that effect.)
Firefox documentation, however, is not clear in this regard. There have been a whole bunch of stern warnings appearing that Extension Signing will be enforced starting with Firefox 48. Looking at the latest (August 16, 2019) of https://wiki.mozilla.org/Add-ons/Extension_Signing, we see the following paragraphs (in order, but not all contiguous): Firefox 48: (Pushed from Firefox 46). Release and Beta versions of Firefox for Desktop will not allow unsigned extensions to be installed, with no override. Firefox for Android will enforce add-on signing, and will retain a preference — which will be removed in a future release — to allow the user to disable signing enforcement. [skip ...] Will there be a setting or other overrides to disable signature checks? Firefox Release and Beta versions will not have any way to disable signature checks. Signature checks can be disabled in other versions, as described in detail below. What are my options if I want to install unsigned extensions in Firefox? The Nightly and Developer Edition versions of Firefox have a preference to disable signature enforcement. There are also be special unbranded versions of Release and Beta that have this preference, so that add-on developers can work on their add-ons without having to sign every build. To disable signature checks, you will need to set the xpinstall.signatures.required preference to "false". type about:config into the URL bar in Firefox in the Search box type xpinstall.signatures.required double-click the preference, or right-click and selected "Toggle", to set it to false. How do the unbranded versions of Firefox work? They work just like Firefox, with two differences: they have a setting to disable mandatory signature checks, and they don't have the Firefox name and logo (instead using a generic name and logo). These builds are available in the en-US locale only. What about private add-ons used in enterprise environments? The ESR release supports signing starting with version 45-based releases. Signing enforcement is enabled by default in these releases, and enforcement can be disabled using the xpinstall.signatures.required preference. In these paragraphs, "Nightly", "Developer" and "unbranded..." are links (and thus highlighted), but "ESR" isn't. Futhermore, you must descend 4 levels of links from the main ESR page at https://www.mozilla.org/en-US/firefox/organizations/ (most of them non-obvious), to find out how to allow unsigned add-ons in the new ESR Firefox. (It turns out to be the same mathod as before.) Also, https://support.mozilla.org/en-US/kb/add-on-signing-in-firefox (which has no explicit date, but mentions May 5, 2019), does say that the Extension Signature requirement can be disabled in ESR, as well as Developer and Nightly. Finally, it seems that although ESR means "Enterprise Support Release" it is *not* considered to be a "Release" in much of the documentation. This is quite confusing, and needs clarification and cleanup. ------------------------------------------------------------ On Mon, 19 Aug 2019 11:31:36 -0500 Mike Kaply <[email protected]> wrote: > The Firefox ESR has always supported turning off extension signing so > you can install local extensions. > > Mike > > On Sun, Aug 18, 2019 at 10:58 AM Paul Kosinski via Enterprise < > [email protected]> wrote: > > > As a long-time Firefox user, I went to ESR because I prefer > > stability to new features, and I especially don't like gratuitous > > changes to the User Interface. The move to Tabs on Top was ugly: I > > think Google started it so that users would view the Web (and hence > > Google) as their computing environment, rather than Windows et al. > > But at least Classic Theme Restorer could fix that. > > > > The move to Quantum killed much of the ability to make Firefox look > > the way the user wanted and was used to. This has meant that users > > had to learn the new interface rather than doing useful work (sort > > of like The Microsoft Office "Ribbon" debacle). And the modern fad > > of replacing text-labeled icons with pure icons means that no one > > can know for sure what they mean, no matter what language they > > speak. (Plus, "hovering" over the icon to get the tool-tip wastes > > more time.) Not all users have to make do with tiny smartphone > > screens which don't have the space for labeled icons. > > > > The move to Quantum also required some really critical add-ons, > > such as NoScript, to be totally reimplemented, and made many other > > add-ons (such as Classic Theme Restore) apparently impossible. In > > the case of NoScript, there may have been a period where the > > overall security of using Firefox suffered in spite of the more > > secure internal structure of Quantum. > > > > And speaking of security, although the idea of requiring add-ons to > > be signed by Mozilla (only!) may be good for the consumer versions > > of Firefox, it is totally inappropriate for the *Enterprise* version > > (ESR). It means that any organization that wants add-ons that > > *need* to be kept private can't use Firefox at all. The notion that > > they could use a local build or an unofficial build (daily etc.) > > could mean that they are violating some other corporate or > > government regulation concerning what software they are allowed to > > use. And how would one even *find* the daily etc. build that is > > essentially identical to the release build? > > > > Since ESR is for enterprise use, surely it should be possible to > > allow enterprise-private add-ons to be loaded in ESR if their > > *hash* is signed by Mozilla. (Mozilla should not be in the business > > of trying to protect enterprises from software they themselves > > write.) In other words, an enterprise would just submit a hash of > > the add-on XPI to Mozilla the way they now can submit the whole > > XPI. Then if so configured (e.g., via about:config) the ESR version > > of Firefox would allow the add-on to be loaded iff its hash passed > > the signature test. To add to "public safety", Firefox could > > display a caveat stating that the add-on belongs to XYZ Corp. and > > is in no way certified by Mozilla. Plus, of course, such > > hash-signed add-ons would never be hosted by Mozilla. _______________________________________________ Enterprise mailing list [email protected] https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to [email protected] with a subject of "unsubscribe"
