Re: How can we utilize latest GPG from RPM repository?

[Ben McGinnes]

On Thu, Feb 22, 2018 at 08:09:31AM -0800, Dan Kegel wrote:
> 
> https://www.open-scap.org/download/ shows they provide an
> open source tool which is in repositories for four redhat-ish distros and
> two debian-ish distros; on Ubuntu, I was able to walk down the
> path of using it a bit, looks a bit rusty, but see
> https://github.com/OpenSCAP/scap-security-guide
> So it doesn't seem to be RHEL-only.  (They have a value-added tool
> that is, of course.)

Interesting and good to know if I'm ever in the unfortunate position
of needing to deal with it directly again.


Regards,
Ben


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How can we utilize latest GPG from RPM repository?

[Dan Kegel]

On Wed, Feb 21, 2018 at 10:22 PM, Ben McGinnes  wrote:
>> 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.
>
> 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.

https://www.open-scap.org/download/ shows they provide an
open source tool which is in repositories for four redhat-ish distros and
two debian-ish distros; on Ubuntu, I was able to walk down the
path of using it a bit, looks a bit rusty, but see
https://github.com/OpenSCAP/scap-security-guide
So it doesn't seem to be RHEL-only.  (They have a value-added tool
that is, of course.)
- Dan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 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  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 
> 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@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How can we utilize latest GPG from RPM repository?

[Ben McGinnes]

On Wed, Feb 21, 2018 at 07:36:08AM -0800, Dan Kegel wrote:
> On Tue, Feb 20, 2018 at 10:16 PM, Ben McGinnes  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


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How can we utilize latest GPG from RPM repository?

[Dan Kegel]

On Tue, Feb 20, 2018 at 10:16 PM, Ben McGinnes  wrote:
> 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.

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

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 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


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why Operating Systems don't always upgrade GnuPG [was: Re: How can we utilize latest GPG from RPM repository?]

[Daniel Kahn Gillmor]

On Tue 2018-02-20 13:18:40 +0100, Dashamir Hoxha wrote:
> One solution to this situation may be to install the latest GnuPG
> in a Docker container, where it can have all the required libraries
> and dependencies that it needs, without disturbing the host OS.

I think this misses the point that it's not just *what does gnupg depend
on* but it's also *what depends on gnupg*.  The dependencies work in
both directions.

> Another solution may be to use a "snap", which is a kind of new
> software packaging invented by Ubuntu:

The basic idea behind "snap" and "flatpak" and other similar tools is
what many people call "bundling" or "vendoring" -- you ship the program
together with all its dependencies, regardless of what dependencies are
on the host system.  it's not a new idea at all, and is quite common on
many platforms, including in some flavors of cowboy web development.

As with docker containsers, this approach doesn't address the other
direction of the dependency graph.  In addition, all of these approaches
have maintenance costs and open questions about responsibility.  if
every app ships with its own bundled copy of libfoo, and a flaw is found
in libfoo, then it needs to be fixed.  can you be sure you've found and
fixed all copies?  Who is responsible for fixing each specific copy?  Do
those maintainers have enough time/attention/living expenses to make
sure vulerabilities and software flaws get patched in all of their
dependencies?  are they willing to re-ship the entire bundle/snap/docker
image for each dependency that needs an upgrade?

I recently heard bundling/vendoring/snaps/docker containers
characterized in the following way, which resonated with me:

Hm, maintaining a complex operating system is hard.  I know, we can
fix that by trying to maintain 100 complex operating systems
instead!

To be clear, i believe that there are contexts where bundling is
actually the right approach.  But it is not an obvious win to me in most
cases.

Regards,

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why Operating Systems don't always upgrade GnuPG [was: Re: How can we utilize latest GPG from RPM repository?]

[Ben McGinnes]

On Mon, Feb 19, 2018 at 10:45:52AM -0800, Daniel Kahn Gillmor wrote:
> 
> How can GnuPG contribute to fixing this problem?  The traditional way
> that many other projects have taken is to define their core programmatic
> functionality into a library with a strict interface guarantees, and
> have explicitly deprecated other use.  The closest that GnuPG comes to
> this technique is GPGME, which is not feature-complete (as compared to
> the gpg executable), and has its own history of both difficult upgrades
> and unclear/surprising semantics.

True, but what it does have available still covers a *lot* of what
people do mainly want to access programmatically.  My trusty key
counter is now done that way (it takes a while to run, but that's due
to the size of the keybox, not due to GPGME).

> It also doesn't have bindings in many popular programming languages.

There is a cunning plan which may provide a bridge to at least in part
address that.

> When programmers in those language want to use GnuPG, their shortest
> path to "something that works" often involves shelling out to gpg,
> rather than binding to GPGME. :/

Yes

> Another thing that would help would be to explicitly and succinctly
> document the preferred ways of interacting with GnuPG in ways that other
> developers find useful.

That would be brilliant, but it requires convincing developers to not
simply document their work, but to actually step back from their
focussed POV and abstract what they're intending to do so we can
determine what will actually be useful to procide all developers.
Otherwise we'll just end up with a bunch of feature requests specific
to the problem each developer happens to be working on at the time
they notify us.

If you can work out a way to get engineers to understand why that's
important ... you'll become very rich shortly thereafter.  ;)

> Perhaps GnuPG could also itself try to detect when it is being used
> programmatically in an unstable way and produce warnings?

Most of the worst of those examples are in bash, how're you going to
tell the difference between that and a user?

> Yet another complementary approach might be to aggressively police
> the ecosystem by finding other software that deends on GnuPG in any
> of the aforementioned brittle ways, and either ask those developers
> to stop using GnuPG entirely, or to provide them with stable,
> well-supported ways to do what they're looking to do.

And people accuse me of being combative!  Wow ... you're brave ...

Moreseriously, though, let's besure we've got an alternative method to
replace whatever their pet project's method is first.

Arguably gpgme-tool might already do that, but we'll see.

> I welcome discussion/suggestions on how we can improve this situation,
> and i *definitely* welcome help in doing the kind of
> ecosystem-perspective work necessary to make it easier to maintain an
> up-to-date branch of GnuPG.

I'm already laying the groundwork on the API side of things, as well
as working on doumentation.

> But shrugging and suggesting it's uncontroversial to upgrade arbitrary
> machines to the latest version of GnuPG doesn't appreciate the scope of
> the problem involved with software maintenance in an active and
> interdependent ecosystem.

Indeed.  I didn't check your buglist ... but I did recall that one of
the dependencies of GMIME is GPGME.  Pretty sure that'll affect a few
packages and libgcrypt & libgpg-error are a dependencies for lots things.

It's exactly this sort of thing which led to the popularity of
installing things the users wanted in /usr/local or /opt or wherever
specifically to prevent the end user use case adversely affecting the
system's use case.


Regards,
Ben


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why Operating Systems don't always upgrade GnuPG [was: Re: How can we utilize latest GPG from RPM repository?]

[Kristian Fiskerstrand]

On 02/20/2018 01:18 PM, Dashamir Hoxha wrote:
> If anybody is willing to give a try to any of these solutions I would
> like to help.

I would be generally cautious for both approaches without proper support
in the surrounding infrastructure. In particular an upgrade to a
depending library would need to automatically cause a rebuild of the
container in the case of a security upgrade when such embedding happens,
which is generally a bad thing unless you have a large scale deployment
and defined QA processes for terminating and replacing containers with
new deployments regularly.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Manus manum lavat
One hand washes the other



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why Operating Systems don't always upgrade GnuPG [was: Re: How can we utilize latest GPG from RPM repository?]

[Dashamir Hoxha]

On Mon, Feb 19, 2018 at 7:45 PM, Daniel Kahn Gillmor 
wrote:

> On Sat 2018-02-17 17:06:54 -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.
>
> Here's one last try to explain the situation.
>
> GnuPG (and the libraries it depends on) are used by (aka "depended on
> by") other libraries and tools, both those integrated into the operating
> system itself, and those that might be externally installed.  Some of
> these dependencies are "brittle".
>

One solution to this situation may be to install the latest GnuPG
in a Docker container, where it can have all the required libraries
and dependencies that it needs, without disturbing the host OS.

But I am aware that this may present some challenges for  normal
usage and may not be suitable except for testing.

Another solution may be to use a "snap", which is a kind of new
software packaging invented by Ubuntu:
 - https://snapcraft.io/
 - https://docs.snapcraft.io/snaps/intro
The idea is that a software is shipped with all the dependencies,
so it does not matter in which OS it is installed, it will always work.

I don't know the details of snaps. Since it is a "containerized software
package" maybe it is not much different from the docker solution
above and maybe has the same challenges/problems.

If anybody is willing to give a try to any of these solutions I would like
to help.

Regards,
Dashamir
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why Operating Systems don't always upgrade GnuPG [was: Re: How can we utilize latest GPG from RPM repository?]

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Monday 19 February 2018 at 8:51:08 PM, in a message with no id,
ed...@pettijohn-web.com wrote:-


> I think gpgme is the answer here as well. If you mean
> specifically
> a python interface to gpgme then it's probably up to
> a python developer to get that rolling.

Python bindings are among those maintained within the GPGME
repository.

See https://wiki.gnupg.org/APIs



- --
Best regards

MFPA  

After all is said and done, a lot more will be said than done.
-BEGIN PGP SIGNATURE-

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWotpwF8UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+rFDAP9aIDxhmkvC8xFKh2TI/JWefO9UNIDUh+0iYom167DTKQD+OQ/iUn5MW6fu
PfJfdRiAMR5fMB7NpFvzcrRbkoXzQQCJApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCWotpwF8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw
REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/0IVD/0ZWM6fz12is1z2FrZq9S9RX/dE
pz4UedrGjWcufMzv39R2V8TS03u0dx+vAzRo8KT05DGtvIna+3FhosnXSRBu3JSZ
jfT3pfA8hIPY2p2lJK0s2haeL98S2Yu3wJ2Yt+KgS9MmyFOSL/022fVDvYFwi+9Y
/oJlQaE5BXBXvS3n/0WsMrZzDcY3nLf5S0eSK9MSd9rM/M4z09KxS2dngj1Sifgv
GIiBYD7MwnZaaIi8WLGYTj6YeXSVMtlHzXa83fNiZtNOmLRI6p8VkMQUTh5Tjt3F
qlDd+zTSkn801IGiivEYfaOQcRylfTqORhSEFZqIUXI4W/uzJ6NL165SMNgfUa9m
UAinMeKWuC8SdJwKU3BcaqhqhdwoI5HjNq4RQm5K833dkjvn8XoBZ/Tk+Xy918oW
5UCsF3w+AZ9pCG1li0ZnCRkyK7BL0LE8qmotRfknyd9pbGkmljbQYYrxBFKtQdjx
QFvV5OymnxeJcFLqa/cWv7Mz2jPNkA5dSIdPEp0Gsq1Of9hfwS8sddJ6Z/bFONa9
WfSam337dgrZv9aa6I7sO9AP28gkKbB+W9TRVi5WW1m3tHqTm9WOXv30HKLuuyeO
f+K9v0NbKbhoUu1KzYPmXbzBzqeRlYgtGac85I/UvVWV4XzN80G8sxoHsg/fPyd5
sMEr+A2cUaWR7F0DUQ==
=VNMJ
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why Operating Systems don't always upgrade GnuPG [was: Re: How can we utilize latest GPG from RPM repository?]

[edgar]

On Feb 19, 2018 12:45 PM, Daniel Kahn Gillmor  wrote:
>
> On Sat 2018-02-17 17:06:54 -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.
>
> Here's one last try to explain the situation.
>
> GnuPG (and the libraries it depends on) are used by (aka "depended on
> by") other libraries and tools, both those integrated into the operating
> system itself, and those that might be externally installed.  Some of
> these dependencies are "brittle".
>
> Brittle software dependencies
> -
>
> GnuPG is under active development, and it has never had a fully-featured
> stable API (Application Programming Interface).  What i mean is, there
> are some capabilities that are only available from the user interface
> (UI), and are not in the stable API.  GnuPG's UI has been constantly
> improving; sometimes that means that older (worse) UI gets deprecated,
> removed, or has its semantics change.
>
> For historical reasons, there are a number of tools that were built
> around some element of the GnuPG UI that was current at the time the
> tool was built.  Even worse, there are a number of tools that assume
> certain behaviors and features of GnuPG's internal storage (e.g. what
> goes on in ~/.gnupg/), which has never been explicitly part of its API
> (confusingly, there are some exceptions where GnuPG upstream *has*
> encouraged other tools to programmatically interact with some elements
> within its internal storage).  Newer versions of GnuPG do different
> things with its internal storage (and as users we get benefits from
> those improvements).
>
> Simply upgrading GnuPG to the latest available version on a server that
> also ships other complex software is likely to lead to breakage
> elsewhere in the OS because of these brittle assumptions and
> dependencies around GnuPG's UI and internal storage.
>
> A case study
> 
>
> For example, the current stable version of the Debian operating system
> is Debian 9 ("stretch"), and it ships a version of the "modern" branch
> of GnuPG.
>
> As one of the GnuPG maintainers for Debian, i was hoping at one point to
> backport the "modern" version of GnuPG to the previous version of Debian
> (Debian 8, "jessie"), which some people still run on servers.  I found
> that such an upgrade would break at least a half-dozen other packages in
> Debian jessie *that i knew of* [0] -- and their breakage would in turn
> likely affect some number of other packages.  This was not an exhaustive
> survey of all possible bugs, just the most visible ones. :/
>
> I have personally given up on the project of backporting modern GnuPG to
> "jessie", because i think what time i can devote to GnuPG maintenance is
> better-spent elsewhere.  I don't have the bandwidth to cope with the
> resultant bug reports in other packages that such a backport would
> produce.  Generally, i encourage users of "jessie" to uprade their
> entire OS to the current version of debian stable, and to take advantage
> of the improvements to GnuPG that way.
>
> What can we do?
> ---
>
> The problems described above point to problems in the ecosystem *around*
> GnuPG, but it also points to concerns about GnuPG's presentation of its
> capabilities *to* the rest of the ecosystem.  To the extent that GnuPG
> offers features that other tools might want to use, when those features
> are not part of an explicit, documented API, the ecosystem apparently
> *does* try to manipulate them anyway, with all the attendant brittleness
> that you can imagine.
>
> How can GnuPG contribute to fixing this problem?  The traditional way
> that many other projects have taken is to define their core programmatic
> functionality into a library with a strict interface guarantees, and
> have explicitly deprecated other use.  The closest that GnuPG comes to
> this technique is GPGME, which is not feature-complete (as compared to
> the gpg executable), and has its own history of both difficult upgrades
> and unclear/surprising semantics.  It also doesn't have bindings in many
> popular programming languages.  When programmers in those language want
> to use GnuPG, their shortest path to "something that works" often
> involves shelling out to gpg, rather than binding to GPGME. :/ 

That doesn't sound secure. Probably shouldn't use such programs on a server. 
Gpgme looks to do everything that it needs to do. Can you specify a function it 
is missing? 

>
> Another thing that would help would be to explicitly and succinctly
> document the preferred ways of interacting with GnuPG in ways that other
> developers find useful.  Perhaps GnuPG could also itself try to detect
> when it is being used programmatically in an unstable way and produce
> warnings?
>
> Yet another complementary approach might be to aggressively police the
> ecosystem by finding other software that deends on GnuPG in any of the
> aforementioned

Why Operating Systems don't always upgrade GnuPG [was: Re: How can we utilize latest GPG from RPM repository?]

[Daniel Kahn Gillmor]

On Sat 2018-02-17 17:06:54 -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.

Here's one last try to explain the situation.

GnuPG (and the libraries it depends on) are used by (aka "depended on
by") other libraries and tools, both those integrated into the operating
system itself, and those that might be externally installed.  Some of
these dependencies are "brittle".

Brittle software dependencies
-

GnuPG is under active development, and it has never had a fully-featured
stable API (Application Programming Interface).  What i mean is, there
are some capabilities that are only available from the user interface
(UI), and are not in the stable API.  GnuPG's UI has been constantly
improving; sometimes that means that older (worse) UI gets deprecated,
removed, or has its semantics change.

For historical reasons, there are a number of tools that were built
around some element of the GnuPG UI that was current at the time the
tool was built.  Even worse, there are a number of tools that assume
certain behaviors and features of GnuPG's internal storage (e.g. what
goes on in ~/.gnupg/), which has never been explicitly part of its API
(confusingly, there are some exceptions where GnuPG upstream *has*
encouraged other tools to programmatically interact with some elements
within its internal storage).  Newer versions of GnuPG do different
things with its internal storage (and as users we get benefits from
those improvements).

Simply upgrading GnuPG to the latest available version on a server that
also ships other complex software is likely to lead to breakage
elsewhere in the OS because of these brittle assumptions and
dependencies around GnuPG's UI and internal storage.

A case study


For example, the current stable version of the Debian operating system
is Debian 9 ("stretch"), and it ships a version of the "modern" branch
of GnuPG.

As one of the GnuPG maintainers for Debian, i was hoping at one point to
backport the "modern" version of GnuPG to the previous version of Debian
(Debian 8, "jessie"), which some people still run on servers.  I found
that such an upgrade would break at least a half-dozen other packages in
Debian jessie *that i knew of* [0] -- and their breakage would in turn
likely affect some number of other packages.  This was not an exhaustive
survey of all possible bugs, just the most visible ones. :/

I have personally given up on the project of backporting modern GnuPG to
"jessie", because i think what time i can devote to GnuPG maintenance is
better-spent elsewhere.  I don't have the bandwidth to cope with the
resultant bug reports in other packages that such a backport would
produce.  Generally, i encourage users of "jessie" to uprade their
entire OS to the current version of debian stable, and to take advantage
of the improvements to GnuPG that way.

What can we do?
---

The problems described above point to problems in the ecosystem *around*
GnuPG, but it also points to concerns about GnuPG's presentation of its
capabilities *to* the rest of the ecosystem.  To the extent that GnuPG
offers features that other tools might want to use, when those features
are not part of an explicit, documented API, the ecosystem apparently
*does* try to manipulate them anyway, with all the attendant brittleness
that you can imagine.

How can GnuPG contribute to fixing this problem?  The traditional way
that many other projects have taken is to define their core programmatic
functionality into a library with a strict interface guarantees, and
have explicitly deprecated other use.  The closest that GnuPG comes to
this technique is GPGME, which is not feature-complete (as compared to
the gpg executable), and has its own history of both difficult upgrades
and unclear/surprising semantics.  It also doesn't have bindings in many
popular programming languages.  When programmers in those language want
to use GnuPG, their shortest path to "something that works" often
involves shelling out to gpg, rather than binding to GPGME. :/ 

Another thing that would help would be to explicitly and succinctly
document the preferred ways of interacting with GnuPG in ways that other
developers find useful.  Perhaps GnuPG could also itself try to detect
when it is being used programmatically in an unstable way and produce
warnings?

Yet another complementary approach might be to aggressively police the
ecosystem by finding other software that deends on GnuPG in any of the
aforementioned brittle ways, and either ask those developers to stop
using GnuPG entirely, or to provide them with stable, well-supported
ways to do what they're looking to do.

I welcome discussion/suggestions on how we can improve this situation,
and i *definitely* welcome help in doing the kind of
ecosystem-perspective work necessary to make it easier to maintain an
up-to-date branch of GnuPG.

But shruggi

Re: How can we utilize latest GPG from RPM repository?

[Konstantin Ryabitsev]

On 02/19/18 04:53, Werner Koch wrote:
> On Fri, 16 Feb 2018 14:38, konstan...@linuxfoundation.org said:
> 
>> (if someone can recommend a better way that only statically links
>> gnupg's own libraries like libassuan and libgpg-error, but uses shared
>> objects for other system libraries, please let me know, as I didn't find
>> any quickie ways to do it!)
> 
> With 2.2.5 you will be able to do that:
> 
>  make -f build-aux/speedo.mk STATIC=1 SELFCHECK=0 \
>  INSTALL_PREFIX=/somewhere/gnupg22  native
> 
> The SELFCHECK=0 is only needed to build from a non-released version.
> You don't need it with a released tarball.

Oh, nice, thanks for putting that in!

Best,
-- 
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How can we utilize latest GPG from RPM repository?

[Werner Koch]

On Fri, 16 Feb 2018 14:38, konstan...@linuxfoundation.org said:

> (if someone can recommend a better way that only statically links
> gnupg's own libraries like libassuan and libgpg-error, but uses shared
> objects for other system libraries, please let me know, as I didn't find
> any quickie ways to do it!)

With 2.2.5 you will be able to do that:

 make -f build-aux/speedo.mk STATIC=1 SELFCHECK=0 \
 INSTALL_PREFIX=/somewhere/gnupg22  native

The SELFCHECK=0 is only needed to build from a non-released version.
You don't need it with a released tarball.

Thanks for your idea.


Shalom-Salam,

   Werner


-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpQ56TMXBPBK.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How can we utilize latest GPG from RPM repository?

[Peter Lebbing]

On 18/02/18 00:06, helices wrote:
> I will probably never understand why wanting to run the most current
> version of gnupg on a plethora of servers is controversial.

I don't think it is. I'm sorry your question didn't get answered
satisfactorily; that's just how things can go on community mailing lists.

I appreciate your well-formulated arguments for running GnuPG v.2.2.

> However, let it be said here and now, if the gnupg community wants the
> use of gnupg to spread far further than a clique of geeks, making its
> use easier for non-geeks is probably the simplest and most direct way.

I really don't think that it is the task for any upstream to provide
packages for distributions. That truly is what the distributions
themselves are for. For some upstreams it might make sense to provide
their own packages for certain distributions, but I think it's more the
exception that the norm.

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

Since nobody answered with "Oh yeah I happen to package it myself, if
you trust me, you can get it here" or "Oh yeah I know of this person who
packages them", etcetera, my guess is that nobody knows of such a
packaging effort. It's hard to answer affirmatively if you don't know
the affirmative answer :-).

Can I point out that even though you did not like Jeffrey Lightner's
response, Dirk Gottschalk and Konstantin Ryabitsev also replied? If you
could indeed just recompile the Fedora packages, that seems like a
pretty direct route. You do become responsible for updates and "security
support" yourself (in what sense is it still support if you do it
yourself, but hey).

And I wonder if perhaps your interpretation of Jeffrey Lightner's words
was a bit more abrasive than he intended them to be when he wrote those
words, but that is something only Jeffrey Lightner himself can
definitively answer.

Back to the matter at hand. Is it possible for CentOS to provide newer
packages than RHEL? I surmise RHEL will probably not listen to you
unless you get a paid support contract. If CentOS cannot significantly
deviate from RHEL, there doesn't seem to be a gratis way to influence
package versions for CentOS, right? You're dependent on someone
providing packages outside of the distribution proper.

Note, by the way, that interoperability between GnuPG 1.4 and 2.1/2.2 is
not that great, and that often distributions rely on GnuPG in their
internals, meaning there might not be a way to remove GnuPG 1.4 from a
system. It's why Debian deprecated 1.4 before packaging 2.1, so people
would not usually have a system where both are installed. If CentOS 7
relies on GnuPG 1.4, you will need to be careful with 2.1/2.2. Their
keyrings can get out-of-sync.

I'm sorry I don't have a ready answer; if I did, I'd have offered it
days ago...

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How can we utilize latest GPG from RPM repository?

[Edgar Pettijohn]

On 02/17/18 17:06, 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

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.


Furthermore, following feature not availabe in 2.0.22 are more than 
nice-to-haves:


  * The file secring.gpg is not used to store the secret keys anymore.
  * All support for PGP-2 keys has been removed for security reasons.
  * The standard key generation interface is now much leaner.
  * Commands to create and sign keys from the command line without any
extra prompts are now available.
  * There is no more need to manually start the gpg-agent.
  * A new format for locally storing the public keys is now used.
  * Revocation certificates are now created by default.
  * The format of the key listing has been changed to better identify
the properties of a key.


Apparently, there is no current solution to our problem similar to 
that we found for our rsyslog example. That is too bad. We will get 
over our disappointment.


However, let it be said here and now, if the gnupg community wants the 
use of gnupg to spread far further than a clique of geeks, making its 
use easier for non-geeks is probably the simplest and most direct way.


Yes, that is my opinion, humble or otherwise.

YMMV

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


Thank you.


On Wed, Feb 14, 2018 at 2:20 PM, helices > wrote:


CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.

We want to move to v2.2.x, and stay current, but we don't want to
download source and compile for dozens of systems.

We want all users to be using the same version all of the time.

Please, advise. Thank you.



Pay someone to package it for you.



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How can we utilize latest GPG from RPM repository?

[helices]

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

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.

Furthermore, following feature not availabe in 2.0.22 are more than
nice-to-haves:

   - The file secring.gpg is not used to store the secret keys anymore.
   - All support for PGP-2 keys has been removed for security reasons.
   - The standard key generation interface is now much leaner.
   - Commands to create and sign keys from the command line without any
   extra prompts are now available.
   - There is no more need to manually start the gpg-agent.
   - A new format for locally storing the public keys is now used.
   - Revocation certificates are now created by default.
   - The format of the key listing has been changed to better identify the
   properties of a key.


Apparently, there is no current solution to our problem similar to that we
found for our rsyslog example. That is too bad. We will get over our
disappointment.

However, let it be said here and now, if the gnupg community wants the use
of gnupg to spread far further than a clique of geeks, making its use
easier for non-geeks is probably the simplest and most direct way.

Yes, that is my opinion, humble or otherwise.

YMMV

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

Thank you.


On Wed, Feb 14, 2018 at 2:20 PM, helices  wrote:

> CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.
>
> We want to move to v2.2.x, and stay current, but we don't want to download
> source and compile for dozens of systems.
>
> We want all users to be using the same version all of the time.
>
> Please, advise. Thank you.
>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How can we utilize latest GPG from RPM repository?

[Konstantin Ryabitsev]

On 02/14/18 15:20, gpg at mdsresource.net (helices) wrote:
> CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.
> 
> We want to move to v2.2.x, and stay current, but we don't want to download
> source and compile for dozens of systems.

I had a similar need (because my users started to use ECC keys).
Unfortunately, there are no simple answers to this -- to upgrade GnuPG
you would need to upgrade the libraries it depends on (such as
libgcrypt, libassuan, etc), and this cascades to a lot of other things.

I suggest you build gnupg-2.2 without shared libraries and make it
available under /opt/gnupg22:

make build-aux/speedo.mk native INSTALL_DIR=/opt/gnupg22 LDFLAGS=-static

(if someone can recommend a better way that only statically links
gnupg's own libraries like libassuan and libgpg-error, but uses shared
objects for other system libraries, please let me know, as I didn't find
any quickie ways to do it!)

You will need to install at least glibc-static for this, alongside all
other compilation tools. Alternatively, you can build and RPM that does
the same thing -- with the bonus that you don't need to build it
statically if you set it up to correctly handle LD_LIBRARY_PATH bits.

> We want all users to be using the same version all of the time.

Is that for documentation purposes, or because you need features from
gnupg-2.2 that aren't in gnupg-2.0?

Best,
-- 
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

RE: How can we utilize latest GPG from RPM repository?

[Lightner, Jeffrey]

CentOS isn't a vendor.   It is a project that does binary compiles of RHEL 
sources.

RedHat is the vendor that creates RHEL and its source is used to make CentOS.   
RHEL is supported by RedHat if you have a subscription.  CentOS has no direct 
support though RedHat hosts the project nowadays.

RHEL (and therefore CentOS) major versions such as 7 start with base upstream 
versions of packages.   RedHat modifies that base upstream package to backport 
bug and security fixes from later upstream packages if relevant to the original 
base.   They then add extended versioning to the RPM name.   

For example on a test system I just looked at  "yum list gnupg2" shows:
Installed Packages
gnupg2.x86_64  2.0.22-3.el7   @anaconda/7.0
Available Packages
gnupg2.x86_64  2.0.22-4.el7   rhel-7-server-rpms

Notice the base upstream for both the installed and the available is 2.0.22 but 
the extended versioning is different (3.el7 vs 4.el7).   You'd have to examine 
the errata to see what is different about the latter.

In general unless there is a specific feature in upstream you need that is not 
in the RHEL/CentOS provided version you should use the RHEL/CentOS version on 
your RHEL/CentOS system.   

If you really want the latest of everything you should use Fedora instead of 
CentOS.   Just be aware that Fedora is bleeding edge and releases a new version 
twice a year.   Generally that means you HAVE to do a full upgrade at least 
once a year as they won't offer updated packages for more than two major 
versions at a time.   For a Production environment that pace of upgrade is 
usually not desirable which is why people use RHEL/CentOS instead.

-Original Message-
From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of Daniel 
Kahn Gillmor
Sent: Wednesday, February 14, 2018 5:31 PM
To: helices; gnupg-users@gnupg.org
Subject: Re: How can we utilize latest GPG from RPM repository?

On Wed 2018-02-14 14:20:10 -0600, helices wrote:
> CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.
>
> We want to move to v2.2.x, and stay current, but we don't want to 
> download source and compile for dozens of systems.
>
> We want all users to be using the same version all of the time.

This sounds like a problem for your operating system and/or package manager.  
GnuPG has a chain of build dependencies which often makes it difficult to just 
import directly from a single RPM.

If you were running a more recent operating system, you'd likely get something 
from the GnuPG "modern" branch as well anyway.

Perhaps you want to ask your operating system vendor what their recommendation 
is for "backports" of specific packages?

  --dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

RE: How can we utilize latest GPG from RPM repository?

[edgar]

On Feb 15, 2018 9:06 AM, "Lightner, Jeffrey"  wrote:
>
> What you’re missing is WHY you want a later upstream version.   Is there a 
> specific feature you’re needing that isn’t in the one that comes with your 
> distro?
>
>  
>
> You can’t have it both ways:  You want to stay on a stable distro/version 
> which is the raison d’etre for RHEL/CentOS but want to have the latest 
> package.    As I noted in my prior post you can get the latest of everything 
> by abandoning CentOS in favor of Fedora at the expense of stability.    Your 
> choice of distro is based on many factors.   Some people even build their own 
> packages all from scratch because they don’t like any of the distros.  
>

Just to add a little extra. Say you have 12 machines. Use one as your build box 
and just build and install to a fake root tar it up and untar it on the rest of 
the machines. Make a few simple scripts to keep track of what files are 
associated with each "package" so you can easily delete them later. Most 
distros packaging systems are too difficult in my humble opinion. Plus you will 
get the software you want built to your needs.

>  
>
> Not all packages have people that build rpm’s for them.   Many FOSS projects 
> seem to prefer building for Debian or something else and MAY package it for 
> whatever distro they like but some don’t package it for anything and expect 
> you to do the legwork yourself.
>
>  
>
> In general if it isn’t in RHEL/CentOS I look for it in the EPEL.  If it isn’t 
> there I almost always download the source then configure/compile it.   This 
> isn’t really a difficult process for most packages.  
>
>  
>
> There ARE other locations that MAY provide a package you want.   Have you 
> looked at rpmfind?  rpmbone?
>
>  
>
> And of course YOU could create the rpm and share it on EPEL yourself so 
> others will have it.
>
>  
>
>  
>
> From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of helices
> Sent: Thursday, February 15, 2018 9:10 AM
> To: gnupg-users@gnupg.org
> Subject: Re: How can we utilize latest GPG from RPM repository?
>
>  
>
> Yes, I know that.
>
> In general, that scheme works well.
>
> However, in another case, rsyslog, a certain function has been broken for 
> many years, and the only fix is to track the developers' most recent 
> versions. In that case, the developers maintain their own repository: 
> http://rpms.adiscon.com ; which is easy to incorporate into: 
> /etc/yum.repos.d/rsyslog.repo
>
> We are hoping something similar is available for gnupg. I have not found 
> that; which is the reason for my posts here.
>
> What am I missing?
>
> Please, advise. Thank you.
>
>  
>
>  
>
> On Thu, Feb 15, 2018 at 7:56 AM, Lightner, Jeffrey  
> wrote:
>
> CentOS isn't a vendor.   It is a project that does binary compiles of RHEL 
> sources.
>
> RedHat is the vendor that creates RHEL and its source is used to make CentOS. 
>   RHEL is supported by RedHat if you have a subscription.  CentOS has no 
> direct support though RedHat hosts the project nowadays.
>
> RHEL (and therefore CentOS) major versions such as 7 start with base upstream 
> versions of packages.   RedHat modifies that base upstream package to 
> backport bug and security fixes from later upstream packages if relevant to 
> the original base.   They then add extended versioning to the RPM name.
>
> For example on a test system I just looked at  "yum list gnupg2" shows:
> Installed Packages
> gnupg2.x86_64                  2.0.22-3.el7                   @anaconda/7.0
> Available Packages
> gnupg2.x86_64                  2.0.22-4.el7                   
> rhel-7-server-rpms
>
> Notice the base upstream for both the installed and the available is 2.0.22 
> but the extended versioning is different (3.el7 vs 4.el7).   You'd have to 
> examine the errata to see what is different about the latter.
>
> In general unless there is a specific feature in upstream you need that is 
> not in the RHEL/CentOS provided version you should use the RHEL/CentOS 
> version on your RHEL/CentOS system.
>
> If you really want the latest of everything you should use Fedora instead of 
> CentOS.   Just be aware that Fedora is bleeding edge and releases a new 
> version twice a year.   Generally that means you HAVE to do a full upgrade at 
> least once a year as they won't offer updated packages for more than two 
> major versions at a time.   For a Production environment that pace of upgrade 
> is usually not desirable which is why people use RHEL/CentOS instead.
>
>
> -Original Message-
> From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] O

Re: How can we utilize latest GPG from RPM repository?

[helices]

Jeffrey, please, your ad hominem accusations are not helpful.

You said, "What you’re missing is WHY you want a later upstream version."

How do you know that I'm missing that? That "why" is not at all relevant to
my question.

You said, "You can’t have it both ways:  You want to stay on a stable
distro/version which is the raison d’etre for RHEL/CentOS but want to have
the latest package."

As you know, CentOS contains thousands of files, and I have given one
example of a need to deviate from the default distribution for rsyslog.
Suffice it to say, we want to do the same with gnupg.

If there is no gnupg solution similar to our rsyslog solution, then we will
do something else.

Simply because I have not found a gnupg solution similar to our rsyslog
solution, does NOT mean that such a solution does not exist.

Hence, my original post here yesterday.

Actually answering my subject question would be helpful. You have not done
that.

Thank you.


On Thu, Feb 15, 2018 at 9:06 AM, Lightner, Jeffrey  wrote:

> What you’re missing is WHY you want a later upstream version.   Is there a
> specific feature you’re needing that isn’t in the one that comes with your
> distro?
>
>
>
> You can’t have it both ways:  You want to stay on a stable distro/version
> which is the raison d’etre for RHEL/CentOS but want to have the latest
> package.As I noted in my prior post you can get the latest of
> everything by abandoning CentOS in favor of Fedora at the expense of
> stability.Your choice of distro is based on many factors.   Some people
> even build their own packages all from scratch because they don’t like any
> of the distros.
>
>
>
> Not all packages have people that build rpm’s for them.   Many FOSS
> projects seem to prefer building for Debian or something else and MAY
> package it for whatever distro they like but some don’t package it for
> anything and expect you to do the legwork yourself.
>
>
>
> In general if it isn’t in RHEL/CentOS I look for it in the EPEL.  If it
> isn’t there I almost always download the source then configure/compile
> it.   This isn’t really a difficult process for most packages.
>
>
>
> There ARE other locations that MAY provide a package you want.   Have you
> looked at rpmfind?  rpmbone?
>
>
>
> And of course YOU could create the rpm and share it on EPEL yourself so
> others will have it.
>
>
>
>
>
> *From:* Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] *On Behalf Of *
> helices
> *Sent:* Thursday, February 15, 2018 9:10 AM
> *To:* gnupg-users@gnupg.org
>
> *Subject:* Re: How can we utilize latest GPG from RPM repository?
>
>
>
> Yes, I know that.
>
> In general, that scheme works well.
>
> However, in another case, rsyslog, a certain function has been broken for
> many years, and the only fix is to track the developers' most recent
> versions. In that case, the developers maintain their own repository:
> http://rpms.adiscon.com ; which is easy to incorporate into:
> /etc/yum.repos.d/rsyslog.repo
>
> We are hoping something similar is available for gnupg. I have not found
> that; which is the reason for my posts here.
>
> What am I missing?
>
> Please, advise. Thank you.
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

RE: How can we utilize latest GPG from RPM repository?

[Lightner, Jeffrey]

What you’re missing is WHY you want a later upstream version.   Is there a 
specific feature you’re needing that isn’t in the one that comes with your 
distro?

You can’t have it both ways:  You want to stay on a stable distro/version which 
is the raison d’etre for RHEL/CentOS but want to have the latest package.As 
I noted in my prior post you can get the latest of everything by abandoning 
CentOS in favor of Fedora at the expense of stability.Your choice of distro 
is based on many factors.   Some people even build their own packages all from 
scratch because they don’t like any of the distros.

Not all packages have people that build rpm’s for them.   Many FOSS projects 
seem to prefer building for Debian or something else and MAY package it for 
whatever distro they like but some don’t package it for anything and expect you 
to do the legwork yourself.

In general if it isn’t in RHEL/CentOS I look for it in the EPEL.  If it isn’t 
there I almost always download the source then configure/compile it.   This 
isn’t really a difficult process for most packages.

There ARE other locations that MAY provide a package you want.   Have you 
looked at rpmfind?  rpmbone?

And of course YOU could create the rpm and share it on EPEL yourself so others 
will have it.


From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of helices
Sent: Thursday, February 15, 2018 9:10 AM
To: gnupg-users@gnupg.org
Subject: Re: How can we utilize latest GPG from RPM repository?

Yes, I know that.
In general, that scheme works well.
However, in another case, rsyslog, a certain function has been broken for many 
years, and the only fix is to track the developers' most recent versions. In 
that case, the developers maintain their own repository: 
http://rpms.adiscon.com ; which is easy to incorporate into: 
/etc/yum.repos.d/rsyslog.repo
We are hoping something similar is available for gnupg. I have not found that; 
which is the reason for my posts here.
What am I missing?
Please, advise. Thank you.


On Thu, Feb 15, 2018 at 7:56 AM, Lightner, Jeffrey 
mailto:jlight...@dsservices.com>> wrote:
CentOS isn't a vendor.   It is a project that does binary compiles of RHEL 
sources.

RedHat is the vendor that creates RHEL and its source is used to make CentOS.   
RHEL is supported by RedHat if you have a subscription.  CentOS has no direct 
support though RedHat hosts the project nowadays.

RHEL (and therefore CentOS) major versions such as 7 start with base upstream 
versions of packages.   RedHat modifies that base upstream package to backport 
bug and security fixes from later upstream packages if relevant to the original 
base.   They then add extended versioning to the RPM name.

For example on a test system I just looked at  "yum list gnupg2" shows:
Installed Packages
gnupg2.x86_64  2.0.22-3.el7   @anaconda/7.0
Available Packages
gnupg2.x86_64  2.0.22-4.el7   rhel-7-server-rpms

Notice the base upstream for both the installed and the available is 2.0.22 but 
the extended versioning is different (3.el7 vs 4.el7).   You'd have to examine 
the errata to see what is different about the latter.

In general unless there is a specific feature in upstream you need that is not 
in the RHEL/CentOS provided version you should use the RHEL/CentOS version on 
your RHEL/CentOS system.

If you really want the latest of everything you should use Fedora instead of 
CentOS.   Just be aware that Fedora is bleeding edge and releases a new version 
twice a year.   Generally that means you HAVE to do a full upgrade at least 
once a year as they won't offer updated packages for more than two major 
versions at a time.   For a Production environment that pace of upgrade is 
usually not desirable which is why people use RHEL/CentOS instead.

-Original Message-
From: Gnupg-users 
[mailto:gnupg-users-boun...@gnupg.org<mailto:gnupg-users-boun...@gnupg.org>] On 
Behalf Of Daniel Kahn Gillmor
Sent: Wednesday, February 14, 2018 5:31 PM
To: helices; gnupg-users@gnupg.org<mailto:gnupg-users@gnupg.org>
Subject: Re: How can we utilize latest GPG from RPM repository?

On Wed 2018-02-14 14:20:10 -0600, helices wrote:
> CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.
>
> We want to move to v2.2.x, and stay current, but we don't want to
> download source and compile for dozens of systems.
>
> We want all users to be using the same version all of the time.

This sounds like a problem for your operating system and/or package manager.  
GnuPG has a chain of build dependencies which often makes it difficult to just 
import directly from a single RPM.

If you were running a more recent operating system, you'd likely get something 
from the GnuPG "modern" branch as well anyway.

Perhaps you want to ask your operating system vendor what their recommendation 
is for "backport

Re: How can we utilize latest GPG from RPM repository?

[helices]

Yes, I know that.

In general, that scheme works well.

However, in another case, rsyslog, a certain function has been broken for
many years, and the only fix is to track the developers' most recent
versions. In that case, the developers maintain their own repository:
http://rpms.adiscon.com ; which is easy to incorporate into:
/etc/yum.repos.d/rsyslog.repo

We are hoping something similar is available for gnupg. I have not found
that; which is the reason for my posts here.

What am I missing?

Please, advise. Thank you.



On Thu, Feb 15, 2018 at 7:56 AM, Lightner, Jeffrey  wrote:

> CentOS isn't a vendor.   It is a project that does binary compiles of RHEL
> sources.
>
> RedHat is the vendor that creates RHEL and its source is used to make
> CentOS.   RHEL is supported by RedHat if you have a subscription.  CentOS
> has no direct support though RedHat hosts the project nowadays.
>
> RHEL (and therefore CentOS) major versions such as 7 start with base
> upstream versions of packages.   RedHat modifies that base upstream package
> to backport bug and security fixes from later upstream packages if relevant
> to the original base.   They then add extended versioning to the RPM name.
>
> For example on a test system I just looked at  "yum list gnupg2" shows:
> Installed Packages
> gnupg2.x86_64  2.0.22-3.el7   @anaconda/7.0
> Available Packages
> gnupg2.x86_64  2.0.22-4.el7
>  rhel-7-server-rpms
>
> Notice the base upstream for both the installed and the available is
> 2.0.22 but the extended versioning is different (3.el7 vs 4.el7).   You'd
> have to examine the errata to see what is different about the latter.
>
> In general unless there is a specific feature in upstream you need that is
> not in the RHEL/CentOS provided version you should use the RHEL/CentOS
> version on your RHEL/CentOS system.
>
> If you really want the latest of everything you should use Fedora instead
> of CentOS.   Just be aware that Fedora is bleeding edge and releases a new
> version twice a year.   Generally that means you HAVE to do a full upgrade
> at least once a year as they won't offer updated packages for more than two
> major versions at a time.   For a Production environment that pace of
> upgrade is usually not desirable which is why people use RHEL/CentOS
> instead.
>
> -Original Message-
> From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of
> Daniel Kahn Gillmor
> Sent: Wednesday, February 14, 2018 5:31 PM
> To: helices; gnupg-users@gnupg.org
> Subject: Re: How can we utilize latest GPG from RPM repository?
>
> On Wed 2018-02-14 14:20:10 -0600, helices wrote:
> > CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.
> >
> > We want to move to v2.2.x, and stay current, but we don't want to
> > download source and compile for dozens of systems.
> >
> > We want all users to be using the same version all of the time.
>
> This sounds like a problem for your operating system and/or package
> manager.  GnuPG has a chain of build dependencies which often makes it
> difficult to just import directly from a single RPM.
>
> If you were running a more recent operating system, you'd likely get
> something from the GnuPG "modern" branch as well anyway.
>
> Perhaps you want to ask your operating system vendor what their
> recommendation is for "backports" of specific packages?
>
>   --dkg
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How can we utilize latest GPG from RPM repository?

[Dirk Gottschalk via Gnupg-users]

Hi.
Am Mittwoch, den 14.02.2018, 14:20 -0600 schrieb helices:
> CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.

> We want to move to v2.2.x, and stay current, but we don't want to
> download
> source and compile for dozens of systems.

> We want all users to be using the same version all of the time.

> Please, advise. Thank you.

You could try to use the packages from Fedora. Actually they distribute
Version 2.2.4 for Fedora 27. In doubt it should be possible to rebuild
the source packages for CentOS.

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350

signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How can we utilize latest GPG from RPM repository?

[Daniel Kahn Gillmor]

On Wed 2018-02-14 14:20:10 -0600, helices wrote:
> CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.
>
> We want to move to v2.2.x, and stay current, but we don't want to download
> source and compile for dozens of systems.
>
> We want all users to be using the same version all of the time.

This sounds like a problem for your operating system and/or package
manager.  GnuPG has a chain of build dependencies which often makes it
difficult to just import directly from a single RPM.

If you were running a more recent operating system, you'd likely get
something from the GnuPG "modern" branch as well anyway.

Perhaps you want to ask your operating system vendor what their
recommendation is for "backports" of specific packages?

  --dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users