On 08/18/2017 01:22 PM, David Sommerseth wrote:
On 18/08/17 19:36, ToddAndMargo wrote:
On 08/17/2017 01:03 PM, David Sommerseth wrote:
On 17/08/17 18:33, ToddAndMargo wrote:
On 08/17/2017 09:23 AM, ToddAndMargo wrote:
Those version checks are rather pointless, IMO.
I agree. It is a paper chase to try to move liability from the card
providers to the merchant.
Don't ever get me started on the changing your passwords
every month thing!
They just compare
"what's the latest released version". It's equally to complain the
Linux kernel on EL7 is insecure and unmaintained because it is
kernel-3.10 and the latest Linux kernel is 4.12. Which is a completely
misleading statement stupid version checkers provides, since the 3.10
EL7 kernel actually carries fixes and improvements from way newer
kernels; backported, been through QA and the complete release machinery
at Red Hat.
Those version checkers can work reasonably well for private consumers,
where running bleeding edge can work without too much risks. But for
the enterprise it is a waste of time and energy, as those environments
wants to have a more controlled and predictable base environment.
How I see it, this all is quite nonsense. Read the Firefox ESR FAQ more
carefully:
"Maintenance of each ESR, through point releases, is limited to
high-risk/high-impact security vulnerabilities and in rare cases may
also include off-schedule releases that address live security
vulnerabilities."
And the current Firefox build in SL7.3 is firefox-52.2. And it gets
regular updates, and the ESR major versions also gets updated.
# grep firefox- /var/log/yum.log*
Jan 20 14:41:03 Updated: firefox-31.4.0-1.el7_0.x86_64
Mar 08 18:41:02 Updated: firefox-31.5.0-2.el7_0.x86_64
Apr 02 22:51:13 Updated: firefox-31.6.0-2.el7_1.x86_64
May 17 21:42:19 Updated: firefox-38.0-3.el7_1.x86_64
Jul 06 00:39:29 Updated: firefox-38.1.0-1.el7_1.x86_64
Aug 13 00:42:56 Updated: firefox-38.2.0-4.el7_1.x86_64
Sep 03 22:34:38 Updated: firefox-38.2.1-1.el7_1.x86_64
Sep 30 22:54:04 Updated: firefox-38.3.0-2.el7_1.x86_64
Nov 06 01:24:16 Updated: firefox-38.4.0-1.el7_1.x86_64
Dec 25 13:12:56 Updated: firefox-38.5.0-3.el7_2.x86_64
Jan 28 11:27:12 Updated: firefox-38.6.0-1.el7_2.x86_64
Feb 19 01:33:19 Updated: firefox-38.6.1-1.el7_2.x86_64
Mar 10 00:40:33 Updated: firefox-38.7.0-1.el7_2.x86_64
Apr 29 21:00:54 Updated: firefox-45.1.0-1.el7_2.x86_64
Jun 17 13:38:47 Updated: firefox-45.2.0-1.el7_2.x86_64
Nov 22 00:37:17 Updated: firefox-45.5.0-1.el7_3.x86_64
Jan 31 15:01:19 Updated: firefox-45.7.0-1.el7_3.x86_64
Mar 06 22:58:39 Updated: firefox-45.7.0-2.el7_3.x86_64
Mar 10 02:35:16 Updated: firefox-52.0-4.el7_3.x86_64
Apr 19 01:57:53 Updated: firefox-52.0-5.el7_3.x86_64
Apr 26 02:11:50 Updated: firefox-52.1.0-2.el7_3.x86_64
Jun 17 01:34:19 Updated: firefox-52.2.0-1.el7_3.x86_64
The first "Jan 20" reference is from 2015(!).
Gee wiz. I didn't say they never did it. I just said they
were crabby about doing it. The times I have approached them
on various security issues they had not repaired, they were
CRABBY with me and refused. So I stop spitting in the wind.
And that is definitely not necessarily the equivalent of running the
latest bleeding edge Firefox or Firefox ESR - neither feature wise or
security patching wise. AFAIK, Midori is not packaged within SL, so
you're trading packaging QA for something unknown.
Midori is a stinker, but it will have to do until I firefox
fixed.
Maybe I will go to the dark side and install Chromium
That is probably somewhat saner, even though you'll need Fedora EPEL to
get a pre-built package - which does not have the same QA process as SL
packages have implicitly.
Do you know anyway to uninstall the recent updates that
caused this?
You need to undo what the tarball you installed did. I'd take the
output of 'tar -tzf $tarball' and review that list of file, and remove
them manually. Then do a 'yum erase firefox' and reinstall it.
The tar bar is extremely simple to undo. It is all in the one directory.
But that was not the question. I wanted to undo the yum update.
