How can we utilize latest GPG from RPM repository?

[Ben McGinnes]

On Sat, Feb 17, 2018 at 05:06:54PM -0600, helices wrote:
> I will probably never understand why wanting to run the most current
> version of gnupg on a plethora of servers is controversial.
> 
> Nevertheless, the two (2) greatest reasons are:
> 
>    1. PCI DSS v3.2
>    2. PCI DSS compliance audits

Ah, now *this* is a pertinent fact that would've helped at the
beginning of the thread and the fact that it wasn't is a clear
demonstration of a tangential point I made further along about getting
people to step back from their drilled in focus so we can identify the
actual needs.

Because these two lines explain *precisely* why you need something like
RHEL or CentOS (certified systems to go with the auditing) *and*
updated crypto.

> Being able to demonstrate that we are using the latest, greatest
> encryption available on every one of our hosts, simplifies that
> portion of the audit equation more than you probably believe.

That's funny ... I'll leave it alone since there have been gaps in my
posting recently.  In future, though, maybe double-check LinkedIn
before making assumptions about everyone here, or anyone.

Some of us have dealt with things a good deal more rigorously
scrutinised than mere PCI-DSS.

> Are there any other questions before I get a direct answer to my
> original subject question?

Not for RPM, not without compiling it yourself, but you said you
didn't want to do that.

As far as I'm aware there's nothing like FreeBSD's port system or pkg
system (or like MacPorts) in addition to rpm with any of the current
distros by default.  They all pick their preferred package manager and
that's their salient feature (along with the current "systemd vs
lol-no-never-in-hell" debate) and point of differentiation.

Although another part of this thread gave Werner an idea for an
addition to 2.2.5 to improve the static-vs-shared libs issue with
GnuPG and the rest of the system.  That might in future improve the
ability for package managers to have independent system libs and user
accessable libs and more recent versions to meet both user and system
requirements more readily.

Precompiled binaries are always going to be architecture dependent or
packed full of extra code to support a broader architecture.  Plus for
auditing purposes you are actually better off using a compiled version
using certified compilers and glibc (which RHEL brings to the
situation).  There's a lot of focus here on Debian and those
distributions it spawned, due to overlapping involvement for some team
members, but even with that hasn't resulted in "official Debian
packages" or whatever.

There are binaries for some system types for which prior releases were
sporadic (early OS X builds, non GPG4Win win32 executables, that sort
of thing), but nothing like you described and specific to a
distribution which is known to remain on much older versions of
everything and backport security fixes to those versions.

In which case, perhaps it is better to simply bite the bullet and
manage a local repo where everything therein meets those requirements.

If it does, I can think of one way to make it pay for itself and it
runs along the lines of subscriber only access to a repo explicitly
intended for PCI-DSS compliance, though it may require more frequent
audits of that part.


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180221/b6c140a3/attachment-0001.sig>