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 :-(
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?
Date: Thursday, April 28, 2016 22:27:16 -0400 From: Jonathan Billings billings@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 Fri, 2016-04-29 at 03:05 +0000, Richard wrote:
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.
It was an unexpected major shock.
The problem remains add-ons just won't install after being downloaded. Perhaps one should revert to FF 38, re-install add-ons and then upgrade to FF 45 - then start playing about to get those add-ons to be re-accepted.
Not exactly my chosen method of making a product "user friendly".
On Fri, 2016-04-29 at 03:05 +0000, Richard wrote:
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.
Thanks for the link. I like the idea of a so-called non-FF branded version (USA english only) which does not re-enforce the Mozilla Approval requirement.
" How will the unbranded versions of Firefox work? " They will work just like Firefox, with two differences: they will have a setting to disable mandatory signature checks, and they will not have the Firefox name and logo (instead using a generic name and logo). They will be available in the en-US locale only. "
Perhaps that might form a suitable replacement for ESR versions ?
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.
On 04/28/2016 10:20 PM, Always Learning wrote:
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.
OK, when red hat releases a firefox update, we build it. It is a rebuild of the upstream code, as is are all other CentOS packages.
So, we will work with the Red Hat maintainer to address any issues, like we did with the unix plice bug .. BUT .. we will build and release any source code that is released for RHEL .. that is what CentOS Linux is, a rebuild of the RHEL Source Code, when it is released.
So, it does not matter if the packages are broken or not. If the CentOS team did not make changes that did the breaking, we will not be issueing fixes UNTIL Red Hat does in the RHEL Source Code. It the centOS team did make a branding change, and that change is responsible for breaking something, we will of course fix that ASAP and release.
In the case of this firefox release, Red Hat has acknowledged they need to fix it in the RHEL Source Code here:
https://bugzilla.redhat.com/show_bug.cgi?id=1221368
Therefore, I have made a new temporary version available here, for people who would opt to get the new version and not wait:
http://people.centos.org/hughesjr/firefox-45.1.0-1.1.el5.centos/
If you want either the 1386 and/or x86_64 versions, please manually download and install them.
Thanks, Johnny HUghes
On Fri, 2016-04-29 at 07:22 -0500, Johnny Hughes wrote:
Therefore, I have made a new temporary version available here, for people who would opt to get the new version and not wait:
http://people.centos.org/hughesjr/firefox-45.1.0-1.1.el5.centos/
Wonderful, marvellous and I'm delightfully (and gratefully) happy again. Brilliant.
Thank you Johnny.
On Fri, April 29, 2016 7:22 am, Johnny Hughes wrote:
On 04/28/2016 10:20 PM, Always Learning wrote:
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.
OK, when red hat releases a firefox update, we build it. It is a rebuild of the upstream code, as is are all other CentOS packages.
So, we will work with the Red Hat maintainer to address any issues, like we did with the unix plice bug .. BUT .. we will build and release any source code that is released for RHEL .. that is what CentOS Linux is, a rebuild of the RHEL Source Code, when it is released.
So, it does not matter if the packages are broken or not. If the CentOS team did not make changes that did the breaking, we will not be issueing fixes UNTIL Red Hat does in the RHEL Source Code. It the centOS team did make a branding change, and that change is responsible for breaking something, we will of course fix that ASAP and release.
In the case of this firefox release, Red Hat has acknowledged they need to fix it in the RHEL Source Code here:
https://bugzilla.redhat.com/show_bug.cgi?id=1221368
Therefore, I have made a new temporary version available here, for people who would opt to get the new version and not wait:
http://people.centos.org/hughesjr/firefox-45.1.0-1.1.el5.centos/
If you want either the 1386 and/or x86_64 versions, please manually download and install them.
It surfaces over and over again... I will try to stress it (from outside, as I am not in CentOS team) again.
CentOS is binary replica of RedHat Enterprise Linux, and this is what it should stay, and we hope it will. We do use it because of what it is. And I at least once thanked myself for choosing RedHat, and then RedHat's descendant CentOS. You may remember when random number generator bug in Debian (great distribution IMHO !!) was discovered (that affected all Debian clones as well: Ubuntu, maemo...). My friend sysadmin next door - whose everything was Debian - was like a crazy re-generating all key pairs, certificates, and still you can't be sure then didn't walk in and... That day (those days actually) I was just sitting relaxed in my chair and thanked myself for choosing RedHat (Fedora and CentOS), as RedHad never had a flop of that level in my recollection.
Let's thank CentOS team for the great job they are doing, and stop forcing them to stress over and over again that CentOS is binary replica of RedHat Enterprise (I know strictly speaking the last in not correct, but it is the most transparent way for me to say it).
Grateful CentOS user,
Valeri
Thanks, Johnny HUghes
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
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.
On 29 April 2016 at 09:55, isdtor isdtor@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 ...
On 04/29/2016 10:21 PM, James Hogarth wrote:
On 29 April 2016 at 09:55, isdtor isdtor@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 ...
Having used C5 desktops until 4 years ago, then C6 until last week and now using C7, some observations. Getting H/w stuff to work has got MUCH easier. Mostly "it just works". With the EPEL and ELrepo most everything one needs to perform normal office desktop functions is just a yum command away. I have tried to remain on the same hardware, but the recent move to C7 makes my 8 year old PC with 8GB of RAM just unacceptable. This machine was a top of the line gaming machine for my son when we built it, now it stalls as it pages stuff to swap - my work load is the same, just seems the new C7 needs more horse-power to function. Now about the desktop, and the tools that come with the system. Gnome 3, Gnome classic, and KDE - historically I just used the Gnome desktop, Nautilus and found managing my remote servers and the web apps I design and administer just worked fine. Transfer of files to and from the remote servers was a simple drag and drop. The system remembered my SSH key passphrase with no special action, now it doesn't, I need to be entering it continually. I think there is a new app to take care of this but haven't yet found the time to research and set it up. Nautilus is now next to useless for my kind of work flow. Darn, they call this progress? Trying to put apps onto the Gnome Desktop - too difficult, I'm sure its possible but once again, far to obscure - they really want me to change my work flow and habits I guess. So I dust off KDE, been a few years since I played with this, but some brief research to find a working file manager show dolphin gets top marks. Used it under Gnome initially, but some stuff just doesn't show on my screen properly. At least I can actually do my job with Dolphin, but it has some quirks, some quite irksome quirks, but at least I am somewhat productive after a week of trying to get used to all the changes. With all the things I do not like about Windoze and Micro$oft, at least their file manager still works intuitively from WindozeXP, Windoze7 and Windoze10 - the only versions I have chosen to use over the last 15 years. So what's gone wrong with the Linux Desktop developers? Hardware upgrade to my son's three year old gaming machine next week, hopefully that will alleviate some of the frustrations of this migration to the latest CentOS 7 workstation. Enough of a rant. Sorry for the hi-jack, I did amend the subject. P.S. I am using C7 for my new servers and that seems to be okay, bit of a learning curve for systemd and systemctl commands, also for firewalld vs iptables - yes I know I can use the old system, but I try to use the systems as much as possible as they come, as I figure that is where things are heading, so learn, use and embrace. e.g. NetworkManager was introduced in C6 - barely workable for a desktop, just a PITA for a server. But with C7 it mostly works as expected, with little need to lock things down. Works great on the desktop. Have a great weekend. Shalom
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 04/29/2016 04:44 AM, Rob Kampen wrote: *snip*
So what's gone wrong with the Linux Desktop developers?
I don't know, but that's why I use MATE.
I get acceptable performance on my T410 thinkpad with 4GB of memory and outstanding performance on my home built desktop with 16GB of memory.
The T410 has been upgraded with an Intel SSD.
Gnome3 on the Thinkpad was just painful.
Anyway, MATE is in EPEL.
There are still some quirks - like what they did with gedit, you've got the "open" button all the way on the left and the "Save" button way over on the right - who the hell thought that was a good idea?
Ah well.
On Fri, April 29, 2016 7:44 am, Alice Wonder wrote:
On 04/29/2016 04:44 AM, Rob Kampen wrote: *snip*
So what's gone wrong with the Linux Desktop developers?
I don't know, but that's why I use MATE.
MATE was a solution for me too. I used gnome on my FreeBSD workstation and laptop till FreeBSD upgraded to ugly new Gnome, then I switched to Mate and am happy ever since.
I convinced myself to not blame free software developers for making fancy (in their opinion) things that interact with me way different from what I am used to and what I like to stay the way it was. This (blooming fanciness) is often their only reward for hard work they do. And some of us who prefer not to accept what hits our productivity, flee elsewhere, thus providing feedback...
Just my $0.02
Valeri
I get acceptable performance on my T410 thinkpad with 4GB of memory and outstanding performance on my home built desktop with 16GB of memory.
The T410 has been upgraded with an Intel SSD.
Gnome3 on the Thinkpad was just painful.
Anyway, MATE is in EPEL.
There are still some quirks - like what they did with gedit, you've got the "open" button all the way on the left and the "Save" button way over on the right - who the hell thought that was a good idea?
Ah well.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Fri, 2016-04-29 at 11:21 +0100, James Hogarth wrote:
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 ...
I am conservative with somethings but adventurous with others.
C5's Gnome desktop is stable and satisfies all my needs because it is reliable and always works well; FF45 being the exception.
C6 is set-up on a faster, quieter development machine with double the RAM and USB3. When my last C5 production server moves to C6, then I'll have to say a gratefully metaphorical farewell to my dependable C5 development machine "its been really great knowing you".
Stability and reliability are essential for basic computer work. C7 has yet to convince me it is worth the considerable investment in time and energy relearning how to operate and use it. That is why Valerie's BSD philosophy appears attractive (the manual from 1998 remains largely unread). I'll stay with C6 for as long as possible.
Please don't demean something (i.e. C5 and its desktop) which has been a wonderful and enjoyable experience.
-
Alice Wonder -
Always Learning -
isdtor -
James Hogarth -
Johnny Hughes -
Jonathan Billings -
Richard -
Rob Kampen -
Valeri Galtsev