Centos replaced well-running customise Firefox with version ESR 45.1.0 * All the add-ons (language dictionaries, Adblock Plus, Classic Theme Restorer etc.) were disabled with no simple method of reactivating them. Reason given was they were "unsigned". * About:config xpinstall.signatures.required = false partially reduced the problem. * Then possible to reactivate some disabled add-ons, but others down-loaded OK but would not install * removing files in ~/.mozilla/firefox/.../extensions.* and restarting was supposed to help However the time-wasting problem remains, so too do the down-loaded extensions in /tmp, example tmp-xxx.xpi Would be really nice if Centos warned its loyal and grateful users of possible problems before those users trustingly replaced working programmes with considerable time-wasting problems. Time spent on trying to return Firefox to a useful and dependable working tool is unavailable for other tasks :-( -- Regards, Paul. England, EU. England's place is in the European Union.
On Fri, Apr 29, 2016 at 02:23:32AM +0100, Always Learning wrote:> Centos replaced well-running customise Firefox with version ESR 45.1.0Errr... you mean Red Hat released a security update (see https://rhn.redhat.com/errata/RHSA-2016-0695.html), and CentOS rebuilt and released it. What, exactly, would you like the CentOS maintainers to do differently? Are you volunteering your time to help? -- Jonathan Billings <billings at negate.org>
> Date: Thursday, April 28, 2016 22:27:16 -0400 > From: Jonathan Billings <billings at negate.org> > > On Fri, Apr 29, 2016 at 02:23:32AM +0100, Always Learning wrote: >> >> Centos replaced well-running customise Firefox with version ESR >> 45.1.0 > > Errr... you mean Red Hat released a security update (see > https://rhn.redhat.com/errata/RHSA-2016-0695.html), and CentOS > rebuilt and released it. > > What, exactly, would you like the CentOS maintainers to do > differently? Are you volunteering your time to help?Basically all they did was to move from the old ESR base (38) to the current one (45) so that they could keep current with the (mozilla) upstream ESR release branch. I don't believe that the 38ESR that rhel/centos was running was particularly "customized". The issue of the signed extension requirement has been in the works for some time, with implementation starting with FF40. Since the previous ESR branch was based on 38, ESR didn't see this until just now when the release was based on 45. The issue for ESR people is that they didn't get eased into it the way standard FF users did - over the course of three releases. FF40 was released in october of last year, so by now hopefully extension developers have gotten their code signed. This explains the extension signing, and timeline, a bit: <https://wiki.mozilla.org/Addons/Extension_Signing> Note that the unsigned override that you used is going away with FF47.
On Thu, 2016-04-28 at 22:27 -0400, Jonathan Billings wrote:> On Fri, Apr 29, 2016 at 02:23:32AM +0100, Always Learning wrote: > > Centos replaced well-running customise Firefox with version ESR 45.1.0 > > Errr... you mean Red Hat released a security update (see > https://rhn.redhat.com/errata/RHSA-2016-0695.html), and CentOS > rebuilt and released it. > > What, exactly, would you like the CentOS maintainers to do > differently? Are you volunteering your time to help?I would really like to help but I lack the time with many many demands on time I don't have. Centos might form a special interests group specifically for the existing Firefox ESR browser. Another poster recently stated Mozilla was dropping ESR versions which is likely to jeopardise browser stability. Ultimately it would be nice for a Firefox folk removing privacy breeches, phoning home, allowing web sites to secretly store data (despite options turned-off) and removal of lots of crap unnecessary for the vast majority of Enterprise users. It could eliminate the constant changes - often apparently just to amuse Firefox developers - which users seem to hate. When using the yum GUI update notification service, no reasons for updates are visible. No good issuing a security improvement when, as Johnny replied in another posting, " With respect to CentOS-5, it seems this patch was not migrated to the 45.0.1 install: https://bugzilla.redhat.com/attachment.cgi?id=1025187 from this bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1221368 " essential parts were omitted. Perhaps Up-Stream were pre-occupied with another fundamental change to the product we know and love ? (well, not C7 yet) I use Firefox extensively for a multitude of tasks. -- Regards, Paul. England, EU. England's place is in the European Union.
Always Learning writes:> However the time-wasting problem remains, so too do the down-loaded > extensions in /tmp, example tmp-xxx.xpiThe reason behind this is the missing patch referenced by Johnny's posting that you referenced in a follow-up. What I would really like to see, talking about SIGs and such, is an rpm for palemoon, but I fear it can't be done on C5. Even C6 only would help, although I'm hesitating to move my main desktop off 5; the C6 desktop simply doesn't have the same stability and performance, and having to log off/log on just because PA behaves irratically is really annoying.
On 29 April 2016 at 09:55, isdtor <isdtor at gmail.com> wrote:> Always Learning writes: > > However the time-wasting problem remains, so too do the down-loaded > > extensions in /tmp, example tmp-xxx.xpi > > The reason behind this is the missing patch referenced by Johnny's posting > that you referenced in a follow-up. > > What I would really like to see, talking about SIGs and such, is an rpm > for palemoon, but I fear it can't be done on C5. Even C6 only would help, > although I'm hesitating to move my main desktop off 5; the C6 desktop > simply doesn't have the same stability and performance, and having to log > off/log on just because PA behaves irratically is really annoying. >Given: RHEL5 goes end of life on 2017-03-31, which is 47 weeks, 6 days, 13 hours, 40 minutes, and 50 seconds from now and that even now the updates are limited to critical (ie remote code execution) pretty much might I suggest now is a good time to be thinking about that future of that system and if not move to C7 at least move to C6? I can't even imagine the pain of using C5 as a desktop in today's world ...