Purebrowser add ons stopped working

Hi all

Found that all my add ons in purebrowser stopped working, saying that they “could not be verified for use in PureBrowser and has been disabled”. This applies to lots of popular add-ons like LastPass.

Seems like it’s related to this blog post on mozilla.

Anyone know a fix or whether this will get fixed in PureOS?

1 Like

I just did an update and I can see that a new version of purebrowser just came into the repos. This version is designed to fix a number of security issues but I’m not sure it will address add-ons as well. Please update and test.

1 Like

@jeremiah worked for me after apt-get update && apt-get upgrade, thanks for all your help.


FYI – Mozilla writes;

" Firefox Add-ons issue update

Late on Friday May 3rd, we became aware of an issue with Firefox that
prevented existing and new add–ons from running or being installed. We are
very sorry for the inconvenience caused to people who use Firefox.

Over the weekend, our team rolled–out a temporary fix for all Firefox
Desktop users — version 66.0.4. This release repairs the certificate chain
to re–enable web extensions, themes, search engines, and language packs
that had been disabled. On May 8, Firefox 66.0.5 has been released, and we
recommend that people update to that version if they continue to
experience problems with extensions being disabled. Update notifications
happen within 24 hours, or you can initiate an update manually.

Look for an in–depth retrospective coming soon on the Firefox blog."

What I see: Firefox has a built in time bomb, or remotely activated trigger, that disables some of its functionality. Is there a browser that does not do that?

1 Like

I’m not quite sure where you got that, and I’d love to know because I suspect my information is wrong.

How I read the above was that there was a bug that caused the system to essentially fail closed. (Or maybe someone forgot to renew an intermediate CA cert which could cause the same symptom) Some people would rather fail closed and secure than fail open and functional. But that’s more a preference, and to a degree situational.

If it were an intentional time bomb would it not have affected people who don’t update before affecting people who keep their browser updated?

To present it briefly:
I install an addon. It’s signature is verified and found valid. I accept it into my system.
At later date signature is revoked for whatever reason, and my earlier decision to run the addon is not being honored anymore.

On my computer, addons stopped working in firefox a few days ago and no fiddling with configuration, nor a downgrade to earlier version would fix them. A classic time bomb, even if it was unintentional - I’ll give Firefox devs a benefit of doubt here, considering that they released a fix very quickly.

Still the bottom line is: The time bomb is there in the form of expiring certificates, and there is no option in Firefox to disable it. I would much preferred getting a notification that “This addon is no longer considered safe due to whatever reason”, rather then have it arbitrariliy and irreversibly disabled.

Certificate revoked or certificate expired? In the former case disabling any software signed with that certificate is probably the correct default behaviour.

The situation is similar to that which occurs with secure web pages, where you have the option of ignoring the problem and continuing anyway (at your own risk), either just this once or “permanently”.

Freedom-respecting software should give you the option of shooting yourself in the foot.

1 Like

I disagree. Software is diffrent from a webpage to warrant different treatment. For example, I have a bunch of CD’s with Debian 4. Did they suddenly transformed into a malware just because they are unsigned?

Revoking a certificate is an unusual step. It could indicate that the certificate’s private key has been stolen and/or that the certificate has been used in an inappropriate manner and/or other nefarious or erroneous possibilities.

Of all the set of software signed by the certificate, there is no way to tell which still has integrity and which never had integrity. You may not even know why the certificate has been revoked.

All software signed by the certificate becomes “suspect”. Clearly the software on CD is not itself changed by revoking the certificate but the software may be, both before revocation and after, compromised (or may be, both before revocation and after, just fine). The signer of the software is indicating something by revoking the certificate. It is a warning flag. The signer of the software may in fact be telling you that the CD is malware - it was malware before but you, and they, did not know that before. It is your state of knowledge that changes, not the CD itself.

If you get a trusted explanation from the signer as to what is going on and that explanation satisfies you that it is safe to continue to use a particular piece of software then there is no problem. In all other situations it is a fairly philosophical question as to whether it is better or worse than the situation that the software is unsigned - but the system should allow you to continue to use the software if you so choose.

1 Like

Guys, it was not revoked. It expired.
Debian wrote in their update notes that only 3rd party addons were affected, not those that were installed as a Debian package.


I’d like to explore the argument that code signing is a time bomb more thoroughly. The purpose, as I understand it is to confirm that yes I (the private key owner) did in fact write this code. Once a certificate expires OR is revoked the certificate validating the code is no longer trustworthy. Being as the certificate is no longer trustworthy the code cannot be validated in that way.

Certificates can be revoked for many reasons, and yes this could be abused by a CA but at some point you have to trust someone or compile it yourself… If you’re paranoid enough to review every piece of code and compile it yourself you would not be affected by this, so you already are trusting the CA.

The intent of this system is to allow anyone in the chain to say “hey my piece was compromised don’t trust anything from me until it’s fixed with a new cert”. In this case the CA cert expired and the certs issued by said expired CA were no longer to be trusted because of that expiration. This worked as designed.

This is my, abridged and possibly flawed, understanding so please do not take it as gospel and know that I will be very appreciative of being provided with new information.

With that said, what do you propose as a better solution?

1 Like

I agree. However, if you design it that way, mark a big red X in your calendar to remind you of the expiration :wink:


Well yes, the humans failed miserably here, that I think we all agree on XD

1 Like

just imagine - some few thousand people suddenly realize their ublock extension just exploded.

well you have to have proprietary javascript enabled in youtube to be able to watch anything so i’m bettting that a few ads here and there didn’t cause the zombie apocalipse but what happened was nasty for sure.

not to mention that for the out-of-the-box firefox version on many fixed-release distros it usually takes a while to get the latest update. mine is still 66.04 although i have studies enabled so ublock works and is at the latest version updated today.

what i find it odd is why a lot of developers are still on github when there is gitlab or savannah for gnu.

My view of the matter:

  1. Expiried certificate is a reason not to install newer version.
  2. Expired certificate is not a reason to touch anything already installed. Once installed - it is my responsibility, not the distributor’s.
  3. Revoked certificate may indicate problem with already installed software. The proper way to handle it is to issue security advisory stating the reason of revocation and recommended action.
  4. In no case should the software uninstall or disable itself autmatically.

A differnce between webpage and installed software: Every time you access a webpage it is like you would install a newer version of the software.


I like this, and think your logic is sound. I honestly don’t know if the validation check knows the difference between expired/revoked and if it does why none of the software I’ve encountered handle things this way.

I do think to expand on your advisory idea it would be good to have either the advisory itself or a link to the advisory when trying to run the application/add-on going forward (with an always ignore option for those who so choose).

I’m curious if pureos handles signed packages/applications this way or not? Does GNU/Linux even check if the code is signed or not? I’m relatively new to GNU/Lunix and I know how MS handles this and know that you do get a prompt where you can ignore cert errors/warnings and install/run anyway but I’ve yet to encounter this with either of the GNU/Linux distributions I’m currently running.

Debian repositories are signed as a whole, meaning the metadata containing checksums of the packages.
Expiry leads to no more updates. See

Revocation most likely has the same effect. In theory some monitoring software could show a warning to the user or send an email. But i don’t think it happens by default.

Edit: revocation is broken


I suffered the add-ons disaster in PureBrowser. UBlock Origin “came back” fine, but LastPass is now a legacy extension. I cannot install it from Mozilla and when I download it from LastPass for Firefox, the download fails (file is corrupt).
Before I continue hacking around, I thought I would ask here for a known solution.

Wild guess: the server is currently overloaded. Try again :slight_smile: