There was a similar issue[0] a few years ago that was only caught a month in advance.
Even better would be to set things up to only do a verify on install instead on every startup.
That would defeat the purpose of verification: "Add-on signing in Firefox helps protect against browser hijackers and other malware by making it harder for them to be installed." [1]
And it's not just malware that was doing that. Microsoft force-installed the ".NET Framework Assistant" into Firefox on Windows, and you had to edit the registry to remove it. [2] If I recall correctly, AVG and Logitech were also among the list of offenders.
[1] https://support.mozilla.org/en-US/kb/add-on-signing-in-firef... [2] https://support.microsoft.com/en-us/help/963707/how-to-remov...
And honestly, I think it is security theater to attempt to defend against attackers on the same or higher privilege level. If microsoft wants to force something down your throat on windows then there's not much you can do.
The problem is that mozilla turns the failures of others into their own problem and then they try to fix it themselves. That scope and responsibility creep leads us to the fallout we're seeing now.
How? These extensions were not being installed through the normal mechanism. The malicious extension installer will just set the flag that says "this extension has been verified".
> And honestly, I think it is security theater to attempt to defend against attackers on the same or higher privilege level.
I understand that, and Mozilla does too: "By baking the signing requirement into the executable these programs will either have to submit to our review process or take the blatant malware step of replacing or altering Firefox." [1]
[1] https://blog.mozilla.org/addons/2015/04/15/the-case-for-exte...
Also, they could still run the verification and prompt the user instead of just forcing the decision.
And the clearly malicious action of modifying Firefox to disable signature verification can and should be flagged by anti-malware software, which runs at a higher privilege level.
[1] Putting aside for the moment the fact that most users now have no extensions installed due to the certificate expiration issue. No Firefox user, myself included, is happy about that.
... How?
I agree with the sibling poster; it sounds like you already lost.
If the user does not want that crap on their machine they should remove the origin instead. We would not have the current situation if mozilla did not assume responsibility and control for problems outside their domain.
At least they could have made this opt-in by asking the user if they want an extra locked down version of firefox that might disable their addons if they are deemed malicious. Then the user could have made an informed choice.
Edit: Let me amend my question - why is it necessary for the certificates to expire? If a plugin is signed by Mozilla, why wouldn't it be trusted once it gets old?
I asked essentially that question earlier, and received some good answers explaining why [1].
Briefly, if something is signed by an expired certificate, whether or not you can trust the signature depends on whether or not the signing took place while the certificate was not expired.
If all you have is the thing and the signature from the code signer, you can't tell for sure when it was signed. If a bad guy has obtained an old signing certificate and its keys, that bad guy can generate new signatures that claim to have been signed while the certificate was valid.
Some code signing systems, such as the one in Windows (and I think the one Apple uses) also use another certificate, from a timestamp service, to prevent this. The way a timestamp service works is you send them a hash of a document, and they generate a certificate signed by them that essentially says "We were shown this hash on this particular date/time".
When you include the timestamp certificate with the signature from the code signer, then when you come across code that was signed by an expired certificate but purports to have been signed while the certificate was still valid, you can check the timestamp certificate to see if that is true. If it is, you can still consider the code signing to be valid.
Forgetting to renew a signing certificate is still bad even if you do this, but not as bad. If Microsoft or Apple forget, it doesn't stop existing applications from working, so end users aren't immediately impacted. It does stop developers from shipping updates or new applications, so still would be a big deal. I could see a bad guy noticing that a company always updates expiring certificates one month in advance, say, and then noticing that a certificate is expiring in just a week, infer that the certificate renewal has slipped through the cracks and is going to expire, and time the use of a critical zero day exploit to fall in the window when updates are broken by the expired certificate.
If it's not a malicious extension, verifying the signature doesen't prevent a forced install.