1954934 - Verify add-on signatures sooner when relevant after a browser update

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, enhancement)

Description

[Rob Wu [:robwu]]

For changes to add-on signature verification to apply, add-on signatures need to verify. This can take up to 24 hours.

We should make sure that if there is any known change to signature state, that signatures are verified immediately.
For example, in the most recent root certificate expiration, the recommendation is to update the browser. But if someone is using an old browser, updating to the latest version does not immediately fix the signatures, and consequently the user may think that the update did not fix things.

When QA was checking the patch to bug 1954818, they also observed that a previously disabled add-on remains disabled, until the timer to trigger immediate signature verification is triggered.

Comment 1

[Rob Wu [:robwu]]

Attachment: Bug 1954934 - Introduce signature verification checkpoint at startup

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/907f5fdd62f6
Introduce signature verification checkpoint at startup r=willdurand

Comment 3

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/907f5fdd62f6

Comment 4

[Alex Cornestean]

Verified as Fixed. Tested on the latest Nightly 138.0a1 from the try builds linked in Comment 2 under Windows 11, Ubuntu 24.04 LTS and macOS 11.3.1.

The extension is re-enabled as soon as the browser starts.

Comment 5

[William Durand [:willdurand]]

Comment on attachment 9473089 [details]
Bug 1954934 - Introduce signature verification checkpoint at startup

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: This will speed-up the resolution of https://bugzilla.mozilla.org/show_bug.cgi?id=1954818 for affected users (which can take up to 24h otherwise).
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It's low risk because the code is covered by tests, verified by QA, and the patch only attempts to re-verify extension signatures once.
• String changes made/needed: N/A
• Is Android affected?: Yes

Comment 6

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/bda61feb6236

Comment 7

[Alex Cornestean]

Verified as Fixed. Tested on the latest Beta (137.0b9/20250320105533 from the try builds linked in Comment 6) under Windows 11 and Ubuntu 24.04 LTS.

The extension is re-enabled as soon as the browser starts.

Comment 8

[Rob Wu [:robwu]]

Attachment: Bug 1954934 - Introduce signature verification checkpoint at startup - ESR128 port

Original Revision: https://phabricator.services.mozilla.com/D242193

Comment 9

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: Users updating from previous version with expired certificate (e.g. intermediate from bug 1954818 or root from https://support.mozilla.org/en-US/kb/root-certificate-expiration) will still have disabled add-ons for up to 24 hours, instead of them being re-enabled immediately on update
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: https://bugzilla.mozilla.org/show_bug.cgi?id=1954818#c2
• Risk associated with taking this patch: Low
• Explanation of risk level: Covered by automated tests, verified by QA already and patch runs logic only once.
• String changes made/needed: None
• Is Android affected?: no

Comment 10

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/b1e5c830ccb2

Comment 11

[Alex Cornestean]

Verified as Fixed. Tested on the latest ESR 128 (128.9.0esr/20250321111107 from the builds linked in Comment 10) under Ubuntu 24.04 LTS and macOS 11.3.1.

The extension is re-enabled as soon as the browser starts.

Comment 12

[Rob Wu [:robwu]]

Attachment: Bug 1954934 - Introduce signature verification checkpoint at startup - ESR115 port

Changes from the original:

• .sys.mjs -> .jsm
• .toml -> .ini
• XPIExports.XPIDatabase -> lazy.XPIDatabase
• invert dev-root pref, since the xpi on ESR115 is signed with the prod
  root instead of the dev root (bug 1886252)

Original Revision: https://phabricator.services.mozilla.com/D242193

Comment 13

[Phabricator Automation]

esr115 Uplift Approval Request

• User impact if declined: Users updating from previous version with expired certificate (e.g. intermediate from bug 1954818 or root from https://support.mozilla.org/en-US/kb/root-certificate-expiration) will still have disabled add-ons for up to 24 hours, instead of them being re-enabled immediately on update
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: https://bugzilla.mozilla.org/show_bug.cgi?id=1954818#c2 ; To verify with root expiration: use ESR115.12 or earlier as "affected build"; To try the intermediate cert expiration, test any ESR115.13 - ESR115.21 build (as long as the hotfix from bug 1954957 has not been deployed).
• Risk associated with taking this patch: Low
• Explanation of risk level: Covered by automated tests, verified by QA already and patch runs logic only once.
• String changes made/needed: None
• Is Android affected?: no

Comment 14

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/363891c83410

Comment 15

[Alex Cornestean]

Verified as Fixed. Tested on the latest ESR 115 (115.22.0esr/20250321162310 from the builds linked in Comment 14) under Ubuntu 24.04 LTS and macOS 11.3.1.

Since the hotfix from Bug 1954957 has been deployed, I edited the extensions.systemAddon.update.url perf so as the hotfix to not get delivered on the tested build and to test this patch exclusively.

Even without the hotfix, the extension is re-enabled as soon as the browser starts.