Update hotfix to avoid disabling extensions when the certificate addition fails
Categories
(Toolkit :: General, defect)
Tracking
()
Root Cause | Corner Case |
People
(Reporter: robwu, Assigned: robwu)
References
Details
(Whiteboard: cert2019)
Attachments
(1 obsolete file)
There are a known ways for certificate adding to fail (bug 1549249 , bug 1549344).
Let's update the hotfix to not force a signature check on failure. Otherwise the hotfix will actually result in add-ons getting disabled. This would already happen anyway when the usual verification timer is triggered.
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment 3•5 years ago
|
||
:keeler, :mythmon, we're going to need review and signing for this update. Thanks!
Comment 4•5 years ago
|
||
Could you add a code path for older versions of Firefox? (Use Components.utils.import instead of ChromeUtils.import and Use XPIProvider.verifySignatures() instead of XPIDatabse.verifySignatures()). Currently this hotfix is deployed to Firefox 59 or earlier, but not working.
Alternatively, could you stop deploying the useless hotfix to older versions?
Comment hidden (obsolete) |
Assignee | ||
Comment 6•5 years ago
|
||
Verification steps once the XPI is signed:
- Download an add-on from AMO (e.g. uBlock origin); save it to your disk.
- Create a profile directory.
- Create a file called "user.js" in it, with the following content:
user_pref("app.normandy.enabled", false);
user_pref("security.nocertdb", true);
- Set system clock to 3rd of May.
- Open Firefox with the given profile directory.
- Install the add-on from step 1.
- Close Firefox, set the system clock to the current time.
- Start Firefox again. Install the signed XPI.
- Open the global JS console (Ctrl-Shift-J on Linux/Windows, Cmd-Shif-J on macOS), and confirm that you see the following two messages:
WebExtensions: failed to add new intermediate certificate: Exception { name: "", message: "Component returned failure code: 0x805a1fe8 [nsIX509CertDB.addCertFromBase64]", result: 2153390056 .....
WebExtensions: Suppressing scheduled signature verification check
- Verify that the add-on from step 1 is still installed.
With the previous version of the hotfix (1.0.2), the result is:
- First error message shows up; Second error message is
WebExtensions: signatures re-verified
- The add-on from step 1 is disabled.
Assignee | ||
Comment 7•5 years ago
|
||
(In reply to Masatoshi Kimura [:emk] from comment #4)
Could you add a code path for older versions of Firefox? (Use Components.utils.import instead of ChromeUtils.import and Use XPIProvider.verifySignatures() instead of XPIDatabse.verifySignatures()). Currently this hotfix is deployed to Firefox 59 or earlier, but not working.
Alternatively, could you stop deploying the useless hotfix to older versions?
The hotfix is written using mechanisms that are only available since Firefox 61 (bug 1454820). The extension isn't loaded in 60 and earlier.
(I'm assuming comment 5 indicates my input isn't needed here any longer.)
Updated•5 years ago
|
Updated•5 years ago
|
Comment 9•5 years ago
|
||
Review was handled on github: https://github.com/mozilla/webext-exp-skeleton/pull/1
This was deployed as a new recipe on Normandy: https://delivery-console.prod.mozaws.net/recipe/763/
Comment 10•5 years ago
|
||
(In reply to Masatoshi Kimura [:emk] from comment #4)
Could you add a code path for older versions of Firefox? (Use Components.utils.import instead of ChromeUtils.import and Use XPIProvider.verifySignatures() instead of XPIDatabse.verifySignatures()). Currently this hotfix is deployed to Firefox 59 or earlier, but not working.
Alternatively, could you stop deploying the useless hotfix to older versions?
I believe we have other compatibility issues with Firefox <= 60, so this new add-on is only targeting 61 and above.
Updated•5 years ago
|
Comment 11•5 years ago
|
||
Verified as Fixed using Windows 10 x64 and macOS 10.13.6 on the Release (66.0.3 - 20190409155332), Beta (67.0b16 – 20190502232159) and Nightly (68.0a1 - 20190503041749) versions of Firefox prior to the 4th of May 2019.
Following the provided STR and the available hotfixes, the results documented in Comment 6 were correctly obtained, confirming the fix.
Comment 12•4 years ago
|
||
Please specify a root cause for this bug. See :tmaity for more information.
Assignee | ||
Updated•4 years ago
|
Description
•