1713628 - Extensions are disabled automatically when the date changes

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, enhancement, P5)

Description

[FireFox]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

Linux.
There are several extensions installed in the browser.
The extensions were installed when the internet was on.
Then we turn off the Internet.
Then we change the date in the operating system. For example, we indicate May 2020.
We launch the browser and work at the computer without the Internet.
After a while, we notice that the browser has disabled all extensions.
The browser apparently decided to do this due to the change in the date of the operating system.
And in order for the extensions to work again, you need to reconnect your computer to the Internet.
And this is very inconvenient.
Please make sure that when you change the date of the operating system, the browser does not disable the extensions.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Rob Wu [:robwu]]

There are multiple security features (not just extensions) that rely on a correctly synchronized clock.

It's not ideal that extensions are disabled when the date is slightly off.

Still, you should not choose a date that is significantly off, because you're probably going to encounter many other broken features.

Comment 3

[Rob Wu [:robwu]]

Can you share the output of about:support so we can see which extension versions you're using?

Comment 4

[FireFox]

It was: Kiwix 3.1.0 and SaveFromNet 9.55.

Comment 5

[Rob Wu [:robwu]]

(In reply to FireFox from comment #4)

It was: Kiwix 3.1.0 and SaveFromNet 9.55.

This extension was published on 13st of December, 2020.

When I try to install the extension (after starting Firefox with faketime '2020-05-01), the callback of the openSignedAppFile task is invoked with aRv being 0x805a3ffb (via the debugger of the Browser Toolbox).
After converting this XPCOM error code to a NSS error code (taking the 16 least significant bits, following the logic of GetXPCOMFromNSSError and nsError.h), it's -(0x805a3ffb & 0xFFFF) = -16379, which maps to MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE (source).

The error code and the reproduction steps suggests that one of the certificates is not yet valid.
The root certificate is valid from 2015 until 2025, so that didn't cause the issue.

The leaf certificate, however, has a validity starting from the date of publishing (13 dec 2020) until ten years later (13 dec 2030).
The certificate was generated by the add-ons signing service, whose source code is in the Autograph repository:

• logic to generate/inject the certificate: https://github.com/mozilla-services/autograph/blob/7acbc43afd4b845d541b82f40ed7f833861a2b64/signer/xpi/x509.go#L192-L211
• parameters (including notBefore and notAfter dates): https://github.com/mozilla-services/autograph/blob/7acbc43afd4b845d541b82f40ed7f833861a2b64/signer/xpi/x509.go#L92-L117

In bug 1267318, code was added to ignore ERROR_EXPIRED_CERTIFICATE, i.e. certificates with a notAfter in the past, at https://searchfox.org/mozilla-central/rev/4163c8f09b03871e053a61f39de020fa09e02ea9/security/apps/AppSignatureVerification.cpp#638
I guess that this specific bug can be resolved by also ignoring certificates with a notBefore in the future, i.e. ERROR_NOT_YET_VALID_CERTIFICATE.

And indeed, after making that change I am able to install the extension.

Comment 6

[Rob Wu [:robwu]]

Attachment: Bug 1713628 - Treat notBefore in the future of signed XPI files as valid + tests

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/04576e8bf14f
Treat notBefore in the future of signed XPI files as valid + tests r=keeler

Comment 8

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/04576e8bf14f