How can we utilize latest GPG from RPM repository?

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

How can we utilize latest GPG from RPM repository?

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.


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|

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

Daniel Kahn Gillmor-7
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
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

GnuPG - User mailing list
In reply to this post by helices
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
_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Lightner, Jeffrey
In reply to this post by Daniel Kahn Gillmor-7
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:[hidden email]] On Behalf Of Daniel Kahn Gillmor
Sent: Wednesday, February 14, 2018 5:31 PM
To: helices; [hidden email]
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
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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:[hidden email]] On Behalf Of Daniel Kahn Gillmor
Sent: Wednesday, February 14, 2018 5:31 PM
To: helices; [hidden email]
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
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|

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:[hidden email]] On Behalf Of helices
Sent: Thursday, February 15, 2018 9:10 AM
To: [hidden email]
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 <[hidden email]> 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:[hidden email]] On Behalf Of Daniel Kahn Gillmor
Sent: Wednesday, February 14, 2018 5:31 PM
To: helices; [hidden email]
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
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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:[hidden email]] On Behalf Of helices
Sent: Thursday, February 15, 2018 9:10 AM
To: [hidden email]


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
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|

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

Edgar Pettijohn
In reply to this post by helices

On Feb 15, 2018 9:06 AM, "Lightner, Jeffrey" <[hidden email]> 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:[hidden email]] On Behalf Of helices
> Sent: Thursday, February 15, 2018 9:10 AM
> To: [hidden email]
> 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 <[hidden email]> 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:[hidden email]] On Behalf Of Daniel Kahn Gillmor
> Sent: Wednesday, February 14, 2018 5:31 PM
> To: helices; [hidden email]
> 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
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|

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

Konstantin Ryabitsev
In reply to this post by helices
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


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

helices
In reply to this post by 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 <[hidden email]> 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
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|

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

Peter Lebbing
In reply to this post by helices
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 <http://digitalbrains.com/2012/openpgp-key-peter>


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Werner Koch
In reply to this post by Konstantin Ryabitsev
On Fri, 16 Feb 2018 14:38, [hidden email] 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.

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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, [hidden email] 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


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Daniel Kahn Gillmor-7
In reply to this post by helices
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 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.

Regards,

        --dkg

[0] examples of breakage:
  https://bugs.debian.org/834281
  https://bugs.debian.org/835075
  https://bugs.debian.org/835592
  https://bugs.debian.org/835465
  https://bugs.debian.org/834514
  https://bugs.debian.org/834600
 

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Edgar Pettijohn

On Feb 19, 2018 12:45 PM, Daniel Kahn Gillmor <[hidden email]> 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 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 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.

>
> 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 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.
>
> Regards,
>
>         --dkg
>
> [0] examples of breakage:
>   https://bugs.debian.org/834281
>   https://bugs.debian.org/835075
>   https://bugs.debian.org/835592
>   https://bugs.debian.org/835465
>   https://bugs.debian.org/834514
>   https://bugs.debian.org/834600
>  
>
> _______________________________________________
> Gnupg-users mailing list
> [hidden email]
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|

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

MFPA-6
In reply to this post by Daniel Kahn Gillmor-7
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Monday 19 February 2018 at 8:51:08 PM, in a message with no id,
[hidden email] 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                  <mailto:[hidden email]>

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

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWotpwF8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+rFDAP9aIDxhmkvC8xFKh2TI/JWefO9UNIDUh+0iYom167DTKQD+OQ/iUn5MW6fu
PfJfdRiAMR5fMB7NpFvzcrRbkoXzQQCJApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCWotpwF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
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
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|

Re: Why Operating Systems don't always upgrade GnuPG

Peter Lebbing
In reply to this post by Daniel Kahn Gillmor-7
On 19/02/18 19:45, Daniel Kahn Gillmor wrote:
> 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.

You are right and I feel stupid for suggesting it is uncontroversial.
Hell, you'd think running Debian stretch/stable (with its 2.1.18) on a
plethora of servers would be uncontroversial, but even that isn't
totally free of controversy. There are people having problems with
adjusting their process to use GnuPG 2.1+.

I am very grateful for all the work you put in to not only fix programs
in Debian depending on /usr/bin/gpg2 being 2.0, but also fix programs
depending on /usr/bin/gpg being 1.4. Because even though
co-installability was considered while designing 2.1, in practice 1.4
and 2.1+ don't mix well.

Thank you.

If done with care and attention, there are still situations where
installing GnuPG 2.2 on what is the most recent version of CentOS/RHEL
is a good thing to do. You have to carefully consider which software
will be using GnuPG, though.

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 <http://digitalbrains.com/2012/openpgp-key-peter>


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Dashamir Hoxha
In reply to this post by Daniel Kahn Gillmor-7
On Mon, Feb 19, 2018 at 7:45 PM, Daniel Kahn Gillmor <[hidden email]> 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:
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
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|

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

Kristian Fiskerstrand-6
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


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (499 bytes) Download Attachment
12