Jump to content

Recommended Posts


Posted
On 5/9/2019 at 12:35 PM, Sampei.Nihira said:
4 hours ago, Sampei.Nihira said:
1 hour ago, Rod Steel said:

Blog of Kev Needham with links to fix's for different Firefox versions, timelines of problem solution, explanations:  Add-ons disabled or failing to install in Firefox

Add-on from Mozilla that fix situation with certificates on Firefox 47 - 56

:unsure:  But, but... Does 52 esr even need that fix? Are you positive? I've got 52.9.1 esr and it's working fine...  :unsure:

 

 

Posted

The only symptom of the problem in 52 ESR seems to be that if you look at the add-ons list it says that they can't be verified for use in Firefox.
They carry on working just fine!
In Firefox 66 they actually all stopped working as they had been blocked!
:yes:

Posted (edited)
16 hours ago, dencorso said:

But, but... Does 52 esr even need that fix? Are you positive? I've got 52.9.1 esr and it's working fine...

Here's the deal:

1. FxESR 52.9.0[1] by default comes with the pref xpinstall.signatures.required set at true; this means that extension signing is by default enabled, much like in the release branch (stable versions 52.0/52.0.1/52.0.2). With that default setting, you can't install (of course) unsigned extensions. But all valid and signed already installed extensions will fail to be verified and will be disabled by the browser, due to the expired intermediate certificate (which is used in the certificate chain to validate signed extensions). Additionally, you won't be able to install further new signed addons or reinstall already existing signed ones (XUL extensions from alternative archives and compatible WEs directly from AMO) because their signature can't be validated!

2. For the group of users that have toggled xpinstall.signatures.required to false, what Mozilla dubbed as "armagaddon 2.0" will manifest itself in the following manner: 

a. Already installed signed extensions will fail to have their signature validated but won't be disabled by the browser; instead, Addons Manager will display the orange security warnings mentioned by @Dave-H that they "... couldn't be verified for use in Firefox" and that you should "Proceed with caution" (wording cited from memory).

b. People often misunderstand that xpinstall.signatures.required;false nullifies extension signing; this is not correct; what that setting does is allow the user to install UNSIGNED extensions; but already signed extensions still need to have their signature validated upon (re-)install; so, much like case 1.) above, you can't install any additional signed extensions on your 52.9.x Firefox instance with the expired intermediate certificate!

TL;DR: You do need to install the new intermediate certificate (due to expire in 2025) in all legacy firefox versions 47 - 56:

https://addons.mozilla.org/en-US/firefox/addon/disabled-add-on-fix-52-56/

(actually, this is applicable to fx 47 - 60, as one can see in its install.rdf file)

PS: NOT ALL signed extensions were affected by "armagaddon 2.0"; but the majority of the ones affected were of the WE type (in Fx <=56.0).

Edited by VistaLover
Posted
6 hours ago, dencorso said:

:unsure:  But, but... Does 52 esr even need that fix? Are you positive? I've got 52.9.1 esr and it's working fine...  :unsure:

 

 

Same here. I had been using 52.9.0 esr until last week when this add-on problem occurred. When I upgraded to 52.9.1 the problem went away. I was hoping the Firefox people would have to release a 52.9.2 esr and fix all the security stuff while they were at it. Too much to hope for I suppose.

Similar story on my linux box. I had Firefox Quantum 60.6.1esr installed when the add-on problem occured, but after the upgrade to 60.6.2esr the add-on problem was gone.

 

Posted

Just installed the fix ( esr 52.9.1 ) All of the ones "affected " I mean the proceed with caution warning went back to normal except of course legacy ublock origin as expected.

Posted
9 hours ago, Tangy said:

except of course legacy ublock origin as expected.

One can hide such remaining warnings (generated by UNSIGNED installed extensions) via CSS code ;) .

If you already have a userstyles manager installed (e.g. the XUL version of Stylish [2.0.7-2.1.1] or Stylem 2.2.4), create a new userstyle named

"AOM -> Add-ons list: Supress "unverified" add-on warnings"

with code:

@-moz-document 
url-prefix(chrome://mozapps/content/extensions/extensions.xul),
url-prefix(about:addons) {
 .warning {
  visibility: collapse !important;
 }
}

This should have an immediate effect; if you don't want to install a userstyle manager, then you can go the userChrome.css route:

1. Locate your profile directory (about:support => Application Basics => Profile Folder => open Folder) and create a text file with path "./chrome/userContent.css" ("./" means the root of your profile folder); the "chrome" subdir may or may not be already present; if not, create it yourself!

2. Open file userContent.css, paste the CSS code posted above and save the file, taking care not to have a ".txt" file extension after saving it. The effect of the CSS code should become apparent after a browser RESTART!

In the event you have Classic Theme Restorer installed in FxESR 52, that extension already comes with a setting to hide AOM warnings...

:P

Posted (edited)
On 5/15/2019 at 6:57 AM, Tangy said:

Just installed the fix ( esr 52.9.1 ) All of the ones "affected " I mean the proceed with caution warning went back to normal except of course legacy ublock origin as expected.

I've just installed the armageddon fix on 52.9.0ESR and still can't install uBlock-firefox-legacy-1.16.4.10 because the extension can't be verified. Is an armageddon fake? :)

Edited by Vistaboy
Posted
22 minutes ago, Vistaboy said:

I've just installed the armageddon fix on 52.9.0ESR and still can't install uBlock-firefox-legacy-1.16.4.10 because the extension can't be verified.

armagaddon-2.0 bug (and fix) has to do with SIGNED extensions; uBlock-firefox-legacy-1.16.4.10 (from GitHub) is an UNSIGNED extension; to install it on FxESR 52.9.0[1], one must first flip (in about:config) xpinstall.signatures.required to false, restart the browser and then attempt to install; to remove warnings generated by installed unsigned extensions, read previous post in this page...

Posted (edited)

uBO v1.17.4 is the latest signed version of uBO (available from Addons.Mozilla.Org) that's compatible with FF 52*. As with all AMO extensions, it uses the WE API set.

Some of us prefer the (unsigned) legacy version, 1.16.4.10, because it lets you enable the WebRTC privacy option that's greyed out on 1.17.4.

But FF will automatically update a legacy uBO version to 1.17.4 unless you either:

  • Turn auto-updates off for uBO, or
  • Install another unsigned add-on, uBlock Origin Updater, which redirects uBO update checks to a site that only lists the legacy versions (1.16.4.x) available from GitHub

 

*Strictly speaking, later uBO versions are also compatible with FF 52, but are flagged as requiring FF 55 or later, so FF won't update uBO to those versions.

Edited by Mathwiz
See asterisk
  • 5 years later...
Posted

And 5 years later...

Can this still be downloaded from Mozilla? Does anyone have a working link? The download CDN and archive links in this post are now dead. Surprisingly, the Mozilla FTP link for Thunderbird 52.9.1 is still alive.

What's the difference between 52.9.0 and 52.9.1 anyway? And why wasn't 52.9.1 officially released by Mozilla if it's the last one? I see @luweitest looked at this very thing, but I didn't understand his conclusion. Something to do with SSL and SHA1? But what about it?

If not Firefox 52.9.0 (or 52.9.1), then what do you suggest I install on a reinstalled Windows XP in 2024? Mypal?

 

Posted
1 hour ago, Hackerman said:

And 5 years later...

Can this still be downloaded from Mozilla? Does anyone have a working link? The download CDN and archive links in this post are now dead. Surprisingly, the Mozilla FTP link for Thunderbird 52.9.1 is still alive.

What's the difference between 52.9.0 and 52.9.1 anyway? And why wasn't 52.9.1 officially released by Mozilla if it's the last one? I see @luweitest looked at this very thing, but I didn't understand his conclusion. Something to do with SSL and SHA1? But what about it?

If not Firefox 52.9.0 (or 52.9.1), then what do you suggest I install on a reinstalled Windows XP in 2024? Mypal?

 

Mypal 68 is a great browser developed by @feodor2. The most recent version is Mypal 68.14.3b. There is even a special SSE release available. Here is the link: https://codeberg.org/Theodor2/Mypal68/releases/tag/68.14.3b

Posted
1 hour ago, AstroSkipper said:

Mypal 68 is a great browser developed by @feodor2. The most recent version is Mypal 68.14.3b. There is even a special SSE release available. Here is the link: https://codeberg.org/Theodor2/Mypal68/releases/tag/68.14.3b

I should have mentioned, I have a Pentium III processor with SSE and MMX running at 733 MHz. Is this good enough?

I am test running Mypal 68.14.3b now in a VM, and I want to know, how do I register it as default browser? It doesn't come with an installer like some other browsers.

54 minutes ago, AstroSkipper said:

Alternatively, @roytam1's browsers New Moon 28 or Serpent 52. Or the Chromium based browser Thorium.

Is this the right download page?

https://rtfreesoft.blogspot.com/search/label/browser

Under "NM28XP build" is the stable release? It too has a "Win32 SSE" release?

The "Win32 IA32" release is not for Pentium III? This is for even older processors? I should get the regular "Win32" if I don't want SSE?
 

palemoon-28.10.7a1.win32-git-20240720-d849524bd-uxp-8fbf81bb8a-xpmod.7z
palemoon-28.10.7a1.win32-git-20240720-d849524bd-uxp-8fbf81bb8a-xpmod-sse.7z
palemoon-28.10.7a1.win32-git-20240720-d849524bd-uxp-8fbf81bb8a-xpmod-ia32.7z

These three are based on the Pale Moon browser? Am I right? And this is what it means to be "New Moon"?

basilisk52-g4.8.win32-git-20240720-3219d2d-uxp-8fbf81bb8a-xpmod-ia32.7z

This one is based on the Basilisk browser? And it's for processors older than Pentium III?

I'm not quite sure of the difference between the designation "Win32" and "Win32 IA32". They are both indicative of 32-bit processor. Or rather, the first indicates 32-bit version of Windows, and the second indicates 32-bit Intel processor.

 

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...