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
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users