How can we utilize latest GPG from RPM repository?

[helices]

Let's cut through these ill-informed suppositions once and for all: If host
compliance was our problem, I would not have posted here at all.

Also, nowhere in this thread have I stated any inability to compile myself.
Having been doing such for 40+ years, that is not our problem either.

Defending processes and systems to egregiously non-technical auditors is a
challenge that grows year by year. If you have not qualified for PCI DSS
Level 1, then you probably have only a cursory understanding of this
situation. Based on previous questions I've posted here in last several
years, it's clear to me that none of the experts here have such experience.

Sometimes, a question is just a question. Overthinking the environment in
which that question was asked adds nothing to the discussion. Now that my
question has been directly answered - thank you, Ben - and indirectly
answered - thank you, to those who did not answer directly - we can move
forward in my enterprise architecture endeavor.

Thank you, Daniel, for describing the complexity of the gnupg problem.

Our new environment will continue with gnupg v2.0.22, because that is the
security level supported by stable and secure Linux operating systems.
Please, do not debate me on this. Yes, we could do otherwise, but that will
incur PCI DSS v3.2 challenges unnecessary to us.

Thank you.

~ helices




On Thu, Feb 22, 2018 at 12:22 AM, Ben McGinnes <ben at adversary.org> wrote:

> On Wed, Feb 21, 2018 at 07:36:08AM -0800, Dan Kegel wrote:
> > On Tue, Feb 20, 2018 at 10:16 PM, Ben McGinnes <ben at adversary.org>
> wrote:
> >>
> >> Because these two lines explain *precisely* why you need something
> >> like RHEL or CentOS (certified systems to go with the auditing)
> >> *and* updated crypto.
> >
> > And when you're on those certified, curated systems, you have
> > access to tools like
> > https://www.open-scap.org/resources/documentation/make-
> a-rhel7-server-compliant-with-pci-dss/
> > to help make sure you're in compliance, I think.
> >
> > I suspect that kind of approach would make passing audits a lot
> > easier than building the latest gnupg release yourself...
> > and is less likely to break things.
>
> In all likelihood, yes ... however open-scap.org is a RedHat service
> and most likely only supplied to RHEL customers seeking PCI-DSS
> compliance along with direct support via their service contract.
>
> If, however, this particular case actually deals with CentOS systems
> and not RHEL, then the OP has elected to forego that type of
> professional service contract from the vendor in order to do it
> themselves.
>
> Which brings us either back to this thread, or a business decision at
> their end regarding whether or not bring their systems back to RHEL
> (it requires changing two files, IIRC, assuming they haven't massively
> modified things) and paying RedHat whatever it takes to get the job
> done.  I cannot predict which they will choose, nor am I willing to
> make a recommendation solely on what's been presented here.
>
> Still, the OP wanted options and now they've been provided.  :)
>
>
> Regards,
> Ben
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180222/f2d9262d/attachment-0001.html>