Mozilla用于签署附加组件的中间签署证书已经过期。这使Firefox认为使用该证书签名的加载项不受信任。该问题已在Bugzilla 1548973和Mozilla的博客中进行了跟踪。
Mozilla已发布了适用于台式机和Android的Firefox 66.0.5和60.6.3 ESR,“其中包含用于重新启用自5月3日起禁用的附加组件的永久性修复程序。 ”建议您将Firefox更新至最新版本。 。此更新取代了研究,这意味着,如果仅启用“研究”以获取此修复程序,则可以在更新到当前版本的Firefox后再次禁用它们。
对于不选择更新到当前版本的Firefox或Firefox ESR的任何人,Mozilla计划发布一个更新,该更新将与Firefox 52至65版本一起使用。该计划是将其作为用户可安装的扩展。期望他们将在有更多信息时更新其博客文章。这是截至美国东部时间5月8日19:28可用的所有信息。
要在Windows或MacOS上更新Firefox版本,请单击右上角的菜单,然后选择“帮助”,然后选择“关于Firefox”。然后,该更新将自动下载,并在重新启动Firefox时应用。
并不是Linux上的所有软件包管理器都已经发布了新版本。如果您的发行版的程序包管理器没有可用的更新,则您可能不得不求助于手动更新(使用首选方法)或尝试以下解决方案之一。
从2019-05-14开始,Mozilla的博客列出了可以为不想更新的旧版Firefox用户安装的扩展(强调):
[注意:以下修复程序要求您启用“研究”,该研究才能使Mozilla在受影响的配置文件中自动下载代码以在Firefox上运行(大多数用户只有一个配置文件)。另外,它要求您启用“允许Firefox将技术和交互数据发送到Mozilla”。如果您出于隐私考虑已将其关闭,则应考虑是否要这样做。您不必将这些设置保持启用状态,但是需要启用它们才能运行可解决此问题的研究。对于那些不想向Mozilla启用“研究”和数据报告的人,请参阅解决方案3(如下;默认情况下,解决方案2会将数据发送给Mozilla以及有时是他们的合作伙伴)。不会打开向Mozilla的报告功能,但我尚未对此进行测试。]
如果启用了“研究”,则Mozilla会针对Release,Beta和Nightly桌面用户的问题进行修复。摘自由Kev Needham撰写并获得CC BY-SA 3.0许可的Mozilla博客:
该修复程序将在接下来的几个小时内自动应用到后台。无需采取任何积极措施即可使附加组件再次运行。
请注意:此修复程序不适用于Firefox ESR或Android版Firefox。我们正在努力为两者发布修复程序,并将在此处和社交媒体上提供更新。
为了在短期内提供此修复程序,我们正在使用研究系统。该系统默认情况下处于启用状态,除非禁用研究,否则无需采取任何措施。Firefox用户可以通过以下步骤检查是否已启用研究:
- Firefox选项/首选项->隐私和安全->允许Firefox安装和运行研究(向下滚动以查找设置)
- 重新启用附加组件后,可以再次禁用研究
该研究最多可能需要六个小时才能应用到Firefox。要检查是否已应用此修复程序,可以在位置栏中输入“ about:studies”。如果该修复程序处于活动状态,您将看到“ hotfix-update-xpi-signing-intermediate-bug-1548973”,如下所示:
You may also see “hotfix-reset-xpi-verification-timestamp-1548973” listed, which is part of the fix and may be in the Active studies or Completed studies section(s).
Mozilla is working on a fix that does not need the studies system. They are aware that some users report that their extensions remain disabled even when both of the above studies are installed. That issue is being tracked in bug 1549078.
If you have studies enabled it may take up to 6 hours for Firefox to check for these new studies.
The user David, in a comment on the blog suggested the following for making Firefox check for studies quicker:
The six-hour wait can be dropped to seconds if you temporarily change the value of “
app.normandy.run_interval_seconds
” inabout:config
, restart, and then change it back to21600
(six hours) after things are working.
I'd suggest you don't set it below 60
seconds, or so. It's certain that it's been more than 1 minute since the last time Firefox checked for studies, or you'd already have the studies installed. Using a number like 60 will give you enough time to have the studies installed and to set the number back to 21600
, without having Firefox check for studies continuously. Just be prepared to change it back to 21600
once the studies are installed and then restart Firefox again.
I tried copying the study/hotfix from another profile. Manually adding the study/hotfix file to another profile did not work. When loading it this way it is recognized as a regular extension. However, it appears to use WebExtension Experiments, which is not enabled for normal extensions in the release version of Firefox.
It's likely that the configuration files in the profile directory could be modified to make it work (they are mostly JSON). However, I did not delve into it sufficiently to figure out what was needed.
It appears that you can directly install the primary "study" by directly going to the URL used for downloading it. I first saw the URL for the [email protected] in this comment by Samuel Vuorela on Mozilla's blog post.
Machavity has an answer on this question describing his experience with downloading the study from that URL and more detail describing where that URL can be found in Mozilla's studies feed. It was his answer which got me to try downloading it directly, so if you find the direct install URL helpful, upvoting his answer would be appropriate. In that answer it's described that while directly downloading/installing the study *.xpi file is functional, doing so will not result in the hotfix being shown in either the studies list or add-ons list. It is shown as a study if Firefox later downloads it through its studies updates.
The content of the download at the above URL is an exact match for the [email protected] file stored in the extensions directory after it is installed through the normal "studies" feed. Looking in the Browser Console indicates that installing directly from the download does not exhibit the same problem that manually installing the *.xpi from a previously downloaded copy does (i.e. it doesn't have the same problems which make installing it via Alternative 2 non-functional).
If you install Firefox Developer Edition or Firefox Nightly in about:config
you can set xpinstall.signatures.required
to false
. This will disable extension signature testing.
Firefox Nightly is a nightly build of the bleeding edge of Firefox development. It is only recommended if you are willing to live with any bugs which may exist.
Both Developer Edition and Nightly send "data to Mozilla — and sometimes our [Mozilla's] partners — to help us [Mozilla] handle problems and try ideas. Learn what is shared."
Firefox permits you to have multiple versions of Firefox installed at one time on a single machine. Personally, I have several versions installed. A fairly easy solution is to install Developer Edition and set xpinstall.signatures.required
to false
. You can then use Developer Edition for a few days until Mozilla gets the whole thing figured out and fixed. You could then go back to using the Release version of Firefox by just running that version.
Setting xpinstall.signatures.required
to false
will not work on the Beta or Release versions of Firefox on Mac or Windows. Doing so has no effect. On Linux, depending on your distribution, the setting may be respected and does work on some distributions of the release version of Firefox.
The preferred solution is to use the "studies" mentioned above. However, if that does not work for you, you can resolve this by disabling signature checking.
Signature checking is a security feature. Disabling it makes Firefox less secure. Once Mozilla gets their certificate issue resolved, it's recommended that you remove this code to re-enable signature checking. With this code installed to disable signature checking, you should be careful to only install extensions that you fully trust (e.g. ones that are hosted on Mozilla Add-ons).
Note: the rest of this answer was originally copied from my answer to How can I disable signature checking for Firefox add-ons? on Stack Overflow, but it's been modified a bit.
The following instructions will disable signature checking on Firefox for the Firefox profile in which you install the files. You are going to be adding some files to the chrome directory under your Firefox Profile directory.
I've tested this on Firefox 66.0.3+.
As of Firefox 69+, it is expected that, in addition to the instructions below, you will need to have toolkit.legacyUserProfileCustomizations.stylesheets
set to true
in about:config
. If it does not exist, then you will need to create it ("new" in the right-click context menu) as a Boolean option. See Bugzilla 1541233 for more detail about the addition of this option.
IIRC, some slightly different code was needed for Firefox 65. I believe I left that code in the try
/ catch
blocks when I modified it for Firefox 66, but I'm not sure about that.
This will not work if you have javascript.enabled
set to false
in about:config
. The default value for that configuration option is true
, so it should be fine unless you've specifically disabled it.
We're going to use a technique which allows you to run arbitrary JavaScript code in the browser context from files stored in your Firefox profile directory. I found how to do this from Haggai Nuchi's GitHub repository: Firefox Quantum compatible userChrome.js. This code is run once when Firefox starts, and then again each time you open a new window.
On Windows, your Firefox profile directory will be %appdata%\Mozilla\Firefox\Profiles\[profileID]
. If you have only one profile, the [profileID]
will be the only directory in the %appdata%\Mozilla\Firefox\Profiles
directory. If you have multiple profiles, you will need to select the one(s) you want to install this hack into.
Once you get to your profile directory, your will need to create a directory called chrome
, if it does not already exist. You will be adding the 2 files below to that directory:
userChrome.css
userChrome.xml
You will then need the following code in userChrome.css
, which is available from Haggai Nuchi's GitHub repository:
/*Enable userChrome.js */ /* Copyright (c) 2017 Haggai Nuchi Available for use under the MIT License: https://opensource.org/licenses/MIT */ @namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul); toolbarbutton#alltabs-button { -moz-binding: url("userChrome.xml#js"); }
You will need userChrome.xml
(slightly modified from the version available in Haggai Nuchi's GitHub repository):
<?xml version="1.0"?>
<!-- Copyright (c) 2017 Haggai Nuchi
Available for use under the MIT License:
https://opensource.org/licenses/MIT
-->
<!-- This has been modified from the version available from
https://github.com/nuchi/firefox-quantum-userchromejs/blob/master/userChrome.xml
to include code by Makyen to disable add-on signing. If you want to load an additional JavaScript
file of your own, please see the original file by Haggai Nuchi.
This modified version is released under both the MIT and CC BY-SA 3.0 licenses.
-->
<bindings id="generalBindings"
xmlns="http://www.mozilla.org/xbl"
xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
xmlns:xbl="http://www.mozilla.org/xbl">
<binding id="js" extends="chrome://global/content/bindings/toolbarbutton.xml#toolbarbutton-badged">
<implementation>
<constructor><![CDATA[
//Worked on FF65 and lower. The 3 different resources are used in different versions of FF.
try {
Components.utils.import("resource://gre/modules/addons/XPIProvider.jsm", {}).eval("SIGNED_TYPES.clear()");
} catch(e) {}
try {
Components.utils.import("resource://gre/modules/addons/XPIInstall.jsm", {}).eval("SIGNED_TYPES.clear()");
} catch(e) {}
try {
Components.utils.import("resource://gre/modules/addons/XPIDatabase.jsm", {}).eval("SIGNED_TYPES.clear()");
} catch(e) {}
//Tested on Firefox 66
try {
const {XPCOMUtils} = ChromeUtils.import("resource://gre/modules/XPCOMUtils.jsm");
XPCOMUtils.defineLazyModuleGetters(this, {
XPIDatabase: "resource://gre/modules/addons/XPIDatabase.jsm",
});
XPIDatabase.SIGNED_TYPES.clear();
console.log('Add-on signing disabled.');
} catch(e) {
console.error(e);
}
]]></constructor>
</implementation>
</binding>
</bindings>
After adding these two files in your profile's chrome directory, you will need to restart Firefox. You can verify that the code is running by looking for "Add-on signing disabled." in the Browser Console (in FF66+; the console output may not be displayed in earlier versions of Firefox).
Add-ons which were disabled or removed by Firefox may not be automatically enabled. You may need to re-install them, or at least manually enable them from about:addons
. You can install them by draging-and-droping the *.xpi file onto a Firefox window and confirming that you want to install, or going to the add-on's page on Mozilla Add-ons.
If you are wanting to get the *.xpi file for any particular extension from Mozilla Add-ons you can download it by right clicking on the "install" button and selecting "Save As", or "Remove".
If you have problems with FF<57, please see my answer to "How can I disable signature checking for Firefox add-ons?" on Stack Overflow. I believe I've incorporated everything from the comments on that question, but the comments describe some problems that other people encountered.
Unfortunately, I don't recall with which version of Firefox this method stopped working. I know I was using it on Firefox 54, 55, 52ESR and FF56.*.
I initially found this solution for disabling forced add-on signature checking in this blog post, which is the original source for the (somewhat modified) code in this answer. Making these changes will allow you to install unsigned add-ons into profiles using the Firefox distribution you modify. For most people, this will be your main Firefox installation. However, if you have installed multiple versions, you will need to make this modification in each installation. However, once you make the modifications, they will remain through normal Firefox updates.
You will need to add a couple of files within the Firefox installation directory. You can find a list of installation directory examples for Windows, Linux, and Mac OS on mozillaZine. The most common install directories are:
You then need to add code below as the file <Install directory>/defaults/pref/disable-add-on-signing-prefs.js
(Windows: <Install directory>\defaults\pref\disable-add-on-signing-prefs.js
):
//This file should be placed in the defaults/pref directory (folder)
//within the Firefox installation directory with the with the name:
// disable-add-on-signing-prefs.js
pref("general.config.obscure_value", 0);
pref("general.config.filename", "disable-add-on-signing.js");
You also need to add the code below as the file <Install directory>/disable-add-on-signing.js
(Windows: <Install directory>\disable-add-on-signing.js
):1
//This file should be placed in the Firefox installation directory
//(folder) with the with the name:
// disable-add-on-signing.js
try {
Components.utils.import("resource://gre/modules/addons/XPIProvider.jsm", {})
.eval("SIGNED_TYPES.clear()");
} catch(e) {}
try {
Components.utils.import("resource://gre/modules/addons/XPIInstall.jsm", {})
.eval("SIGNED_TYPES.clear()");
} catch(e) {}
With the current release version of Firefox, I've been using this solution for a while now to have a few extensions I built for my own use installed and to test new versions of extensions I'm working on (when I want to test in the Release version instead of Firefox Developer Edition or Nightly).
NOTE: In about:addons
Firefox may show (under some conditions) the add-on as enabled (not greyed-out), but have text stating that the add-on "could not be verified and has been disabled". The text is not accurate! The add-on is enabled and functioning.
[This is an explanation of older code, but the current code is very similar.]
Within resource://gre/modules/addons/XPIProvider.jsm
the const SIGNED_TYPES
is defined as a Set
. In order for an add-on to require signing, its type must be a member of that Set
. The Set.prototype.clear()
method is used to clear all entries from the Set
. This results in no add-on types which require signing (code 1, code 2).
如果你愿意,你可以单独为任何类型的禁用签名检查"webextension"
,"extension"
,"experiment"
,或"apiextension"
。
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句