SCIENTIFIC-LINUX-USERS Archives

August 2017

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
David Sommerseth <[log in to unmask]>
Reply To:
Date:
Fri, 18 Aug 2017 22:22:24 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (158 lines)
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:
[...]
>> You do realise that firefox-52 packaged for SL7 is the Firefox ESR
>> edition?
>> <https://www.mozilla.org/en-US/firefox/organizations/faq/>
> 
> Yes I do.  All bugs and security flaws frozen in place for those
> that don't like to upgrade their software and those that get
> tired of having to respin an RPM every month or so due
> to the rapid pace of Firefox's development.  EL Linux
> is an anti-Kaisen OS and Red Hat gets CRABBY about having
> to update things and often does not.


This is simply not true.  Read below.

>> Even though it's a while since I've looked at the PCI-DSS stuff; but I
>> do not ever recall it requiring specific versions of software.  
> 
> I required that you be up to date on all your software.
> On the Windows side, I run Kaspersky's "vulnerability Scan"
> which looks at all your installed software and lets you know
> what is out of date (Acrobat Reader, Java, Firefox, Java,
> etc.).  Without Kaspersky. I'd have to go through each
> program one at a time, which is pain in the neck.


Those version checks are rather pointless, IMO.  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.

>> I do
>> remember it saying something about running up-to-date OS and
>> applications though.  Firefox ESR releases are the browser equivalent to
>> "Enterprise Linux".  So ESR releases should really fit the bill for
>> PCI-DSS.
> 
> On an EL Linux install only.  On Windows, no one will put up
> with all the bugs and missing features.  This is why I have
> to stay current.


ESR major releases gets roughly 1 year old before a new rebase.  Yes,
these old lagging Firefox releases was a true pain in EL5 which didn't
have ESR releases.  I don't recall the whole story for EL6 - but that is
also using ESR releases these days.

> The ESR would probably get you off the hook liability wise,
> but since PCI is not about security, but rather about liability
> shifting, if you get hacked, the lawyers could make a case that
> you knowingly used a version of Firefox with know security flaws.


Which would be a complete false statement, if you are running the latest
released Firefox ESR version, which gets security fixes throughout its
life cycle.

> The lawyers are trying to make the case that you should have to
> pick up the financial liability for all the costs of the breach.
> It could be argued back that the ESR slipstreams security
> patches into its release, but it would be counter argues that
> in reality, they seldom do.


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(!).

As already said:  Latest major version does not mean it is the only
secure version.

Running bleeding edge Firefox is just a completely different rabbit hole
when needing to do the packaging yourself.  Doing this effort yourself
means you need to actually build RPMs constantly for each minor patch
update they come with, QA them properly to be on the same quality level.

With the ESR versions already packaged in SL, that job is handled by
someone else; even Red Hat have done QA on their builds before the
.src.rpms are made available for CentOS and SL.

And as the list above will tell you, the ESR releases gets regular
updates from upstream and hits stock SL installs.

> Until I get this figured out, I have been using weird old Midori.


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.

> 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.


-- 
kind regards,

David Sommerseth

ATOM RSS1 RSS2