Re: Agent forwarding issue

[Todd Zullinger via Gnupg-users]

Hi,

Werner Koch via Gnupg-users wrote:
> On Fri,  5 Apr 2024 13:03, Todd Zullinger said:
> 
>> In such a case, it sounds like it may be reasonable to use
>> the normal socket?  Until the remote side is updated to
> 
> In fact, I also did this for some time but later came up with 
> 
>   CommitDate: Wed Oct 12 11:30:35 2022 +0200
> 
> agent: Introduce attribute "Remote-list" to KEYINFO.
> 
> * agent/command.c (do_one_keyinfo): Add arg list_mode.  Check
> attribute Remote-list.
> (cmd_keyinfo): Change semantics to return nothing in restricted list
> mode.
> 
> which is
> 
>   *** Remote-list
>   Allow to list the key with the KEYINFO command from a remote machine
>   via the extra socket.  A boolean value is expected; the default is
>   "no".  Note that KEYINFO will anyway provide information if the
>   keygrip is specified.
> 
> Not exactly your problem but somehow related.

Neat.  I have probably read agent/keyformat.txt before, but
not in a long time and I never had any reason to consider
editing the .key files.

This caused me to re-read the document and I'll likely add
an additional Token: line to note the two cards which hold a
new key (which I have yet to start using).  That should make
it easier to move between the cards, it sounds like.

In the process, I spotted a few minor typos and sent a patch
to gnupg-devel.

Thanks again, Werner!

-- 
Todd


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

Re: Agent forwarding issue

[Todd Zullinger via Gnupg-users]

Bee via Gnupg-users wrote:
> In the mean time, you could put something along the lines of:
> 
> {CmdCalls ; } 2>&1 | grep -v -e "^gpg: problem with fast path key
> listing: Forbidden - ignored$" or something, to keep that output out
> of your stderr stream.

I think there's a downside to that (but I could always be
wrong).  Redirecting stderr to stdout would prevent mutt (or
whatever tool was using being used) from being be able to
display output only from stderr.  That is helpful when the
exit status is 0 but there were warnings, as in this case.

> If something else unexpected displays, you'll get more issues, but
> then you probably want to know if / when / should that happen.
> 
> If you add --quiet now, even when the change below happens later, your
> script above won't need to change again.

Indeed, if Werner weren't so quick, perhaps I would have
considered some sort of adjustment.  Though I try to use the
mutt's contrib/gpg.rc unaltered so I don't have to remember
to merge in fixes they make there.

This does remind me that I should re-evaluate using  gpgme
as the backend.  I don't recall why I disabled that now.  It
may have been for an issue which is long-since resolved. ;)

-- 
Todd

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

Re: Agent forwarding issue

[Todd Zullinger via Gnupg-users]

Hi Werner,

Werner Koch via Gnupg-users wrote:
>> gpg: problem with fast path key listing: Forbidden - ignored
> 
> I'll suppress that message in --quiet mode for the next release.

Excellent, thanks!

> When doing a secret key listing (which happens with -K but also in
> --with-colons mode) gpg walks over all public keys and asks the agent
> for each key whether a corresponding secret key exists.  With many
> secret keys this is quite some overhead and thus gpg first tries to a
> get a listing of all secret keys (the keygrips) and later can do a fast
> memcmp instead of an IPC call.

In theory, would this not occur if I cleaned up the keyring
a bit.  I've got ~350 public keys.  Some are likely expired
or no longer useful.

This is without any sort of auto-key-locate enabled -- just
years or accumulating keys.  It doesn't _seem_ like that
many keys to have around...

> If you use the extra-socket certain operations are forbidden so that a
> rogue gpg version on the remote site won't be able to change passwords,
> export secret keys, or get a listing of all available secret keys.  This
> is why you see this diagnostic.

I manage the remote system and consider it reasonably
secure, to the extent any online system can be call
"secure."  It's not much less secure than the system from
which I am forwarding, other than that I'm not physically
beside it.

In such a case, it sounds like it may be reasonable to use
the normal socket?  Until the remote side is updated to
silence this via --quiet, at least.

I saw you pushed the change already, so I applied it to the
build on the remote host and can confirm it does the trick.

Thanks for the quick reply, fix, and additional details!

Cheers,

-- 
Todd

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

Agent forwarding issue

[Todd Zullinger via Gnupg-users]

Hi,

I have been working on setting up agent forwarding¹.

One issue which I have not yet found a solution for is that
gpg prints the following to stderr when performing actions
involving the agent:

gpg: problem with fast path key listing: Forbidden - ignored

Both hosts are running gnupg-2.4.5, based on the Fedora
packages.

With mutt, this causes the signing to pause after entering
the password, as stderr is not empty (I think this is the
reason, anyway).  Can this warning be avoided or silenced
(without directing stderr to /dev/null)?

I can't find much information about it, but it seems like
while this is something useful to note, after seeing it once
it is simply needless.

I believe this is because I've used the extra socket, which
seems like the proper thing to do with agent forwarding, but
perhaps isn't worth the hassle?  I'm not too eager to
forward the regular agent when I can use a more restricted
socket.

¹ https://wiki.gnupg.org/AgentForwarding

Thanks,

-- 
Todd

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

Re: 32768-bit key

[Todd Zullinger via Gnupg-users]

Robert J. Hansen via Gnupg-users wrote:
>> I don't know that there's anything to file a bug about.  I
>> don't see any non-rsa4096 keys on the Tails website:
> 
> One of their certificates has a Curve-25519 subkey.  I wonder if that's what
> the original poster saw, and mistook it for being a 25,519-bit subkey.

Ahh, that's a very good guess. I missed that sub key while I
was skimming the list of keys.

-- 
Todd


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

Re: 32768-bit key

[Todd Zullinger via Gnupg-users]

Robert J. Hansen via Gnupg-users wrote:
>> The TailsOS team has a key that's wy over 16384-bit.
> 
> I suggest filing a bug report with them and asking them why they ignore the
> best practices of cryptography.

I don't know that there's anything to file a bug about.  I
don't see any non-rsa4096 keys on the Tails website:

https://tails.net/doc/about/openpgp_keys/

-- 
Todd


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

Re: [Announce] GnuPG 2.4.1 released

[Todd Zullinger via Gnupg-users]

Werner Koch via Gnupg-users wrote:
> On Fri, 28 Apr 2023 11:21, Todd Zullinger said:
> 
>> It seems neither of these files have not made it to the
>> server yet:
> 
> Sorry for that.  I have used a new build machine and obviously forgot
> one of the last steps. Most of the release process is scripted but the
> final upload needs to be done manually (after signing, copying to the
> internal archive, updating the repo, writing announcement and updating
> the web page).
> 
> Fixed after Bernhard called me at home.

Sorry it interrupted your weekend.  Thanks for the new
release and all of your work on GnuPG and OpenPGP. :)

-- 
Todd


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

Re: [Announce] GnuPG 2.4.1 released

[Todd Zullinger via Gnupg-users]

Hi,

Werner Koch via Gnupg-users wrote:
> Getting the Software
> 
> 
> Please follow the instructions found at  or
> read on:
> 
> GnuPG may be downloaded from one of the GnuPG mirror sites or direct
> from its primary FTP server.  The list of mirrors can be found at
> .  Note that GnuPG is not
> available at ftp.gnu.org.
> 
> The GnuPG source code compressed using BZIP2 and its OpenPGP signature
> are available here:
> 
>  https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.4.1.tar.bz2 (7169k)
>  https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.4.1.tar.bz2.sig

It seems neither of these files have not made it to the
server yet:

$ curl -I https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.4.1.tar.bz2
HTTP/1.1 404 Not Found
Date: Fri, 28 Apr 2023 15:19:07 GMT
Strict-Transport-Security: max-age=31536000
Accept-Ranges: bytes
Connection: close
Content-Type: text/html; charset=ISO-8859-1

$ curl -I https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.4.1.tar.bz2.sig
HTTP/1.1 404 Not Found
Date: Fri, 28 Apr 2023 15:19:07 GMT
Strict-Transport-Security: max-age=31536000
Accept-Ranges: bytes
Connection: close
Content-Type: text/html; charset=ISO-8859-1

-- 
Todd


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

Re: gpg: can't handle public key algorithm 18

[Todd Zullinger via Gnupg-users]

Mike Schleif wrote:
> Yes, I see that.
> 
> However, our public key was generated by our GPG; and this file is
> encrypted with our public key, since there is NO missing "secret key" error.
> 
> Why, then, the subject error message?

Perhaps the file is signed by an ECDH key?  I can only
guess.

You might want to try the --list-packets option on the
encrypted message.  Adding -v (or -vv) when decrypting might
help show the issue.

-- 
Todd


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

Re: gpg: can't handle public key algorithm 18

[Todd Zullinger via Gnupg-users]

Mike Schleif wrote:
> $ gpg --version
> gpg (GnuPG) 2.0.22
> libgcrypt 1.5.3
> 
> $ cat /etc/system-release
> CentOS Linux release 7.9.2009 (Core)

Algorithm 18 is ECDH, which is not supported by gpg on
CentOS 7.  You can confirm this in the Pubkey line of the
gpg --version output:

  $ gpg --version
  gpg (GnuPG) 2.0.22
  libgcrypt 1.5.3
  [...]

  Home: ~/.gnupg
  Supported algorithms:
  Pubkey: RSA, ?, ?, ELG, DSA
  Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
  CAMELLIA128, CAMELLIA192, CAMELLIA256
  Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
  Compression: Uncompressed, ZIP, ZLIB, BZIP2

On a newer Fedora system, ECDH is present:

  $ gpg --version --no-copyright
  gpg (GnuPG) 2.4.0
  libgcrypt 1.10.1-unknown
  [...]

  Home: /home/user/.gnupg
  Supported algorithms:
  Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
  Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
  CAMELLIA128, CAMELLIA192, CAMELLIA256
  Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
  Compression: Uncompressed, ZIP, ZLIB, BZIP2

-- 
Todd


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

Re: Difference between versions--Question

[Todd Zullinger via Gnupg-users]

K S via Gnupg-users wrote:
> It would be helpful to know why I can't get compression in my build. I've
> tried to build from source three times now.
> 
> There are so many packages in Ubuntu with zip, zlib, and bzip2 in the name
> I can't begin to try them all. I've looked at config.log and it doesn't
> give much help.

The config.log should show some information about the
compression algorithms, likely found searching for "zip" in
the output.

Building from source does require a bit of familiarity with
the system on which you are building.  While you shouldn't
need to randomly try all the packages, knowing where to look
for ideas will help.

I don't use Ubuntu or Debian, but if I were trying to build
gnupg from source I'd start by looking at what build
dependencies are required by the system packages.

In the case of gnupg, you can see that in the debian/control
file:

https://salsa.debian.org/debian/gnupg2/-/blob/7f5e9b1b/debian/control#L9-43
https://git.launchpad.net/ubuntu/+source/gnupg2/tree/debian/control#n10

You can install those build dependencies via something like:

apt-get build-dep gnupg2

The debian/rules file is usually also interesting; seeing
what configure and make options are used can be helpful.

Some of the dependencies for the current gnupg may be newer
than what is required by the gnupg2 package in Ubuntu and/or
provided by the OS.  You may first need to build those newer
dependencies.

If so, you need to be careful not to interfere with the OS
libraries which are used by other packages on the system.
It can get "interesting" trying to update something which is
quite a core dependency of the operating system.

-- 
Todd


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

Re: GnuPG 2.2.36 released

[Todd Zullinger via Gnupg-users]

Bernhard Reiter wrote:
> Am Montag 11 Juli 2022 14:50:24 schrieb Konstantin Ryabitsev via Gnupg-users:
>>> See https://dev.gnupg.org/T5949#159890 for why it doesn't work for you.
>>
>> Ah, okay, that's unfortunate. I guess I'll skip this release, since I can't
>> verify it without building gnupg from scratch (without verifying it first).
> 
> Maybe it helps to report the problem of missing crypto algorithms to your
> GNU/Linux distribution.

They aren't really missing but rather intentionally removed
due to legal issues on Fedora/Red Hat.  This came up not so
long ago:

https://lists.gnupg.org/pipermail/gnupg-users/2022-May/066054.html

With the current Fedora (36), it's possible to enable these
ciphers via '--with brainpool' when building the libgcrypt
srpm.

Hopefully the legal issues will be cleared sometime soon and
Fedora will stop stripping brainpool.

It's frustrating that the releases are signed with a cipher
that cannot be verified on a reasonably popular distro.

-- 
Todd


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

Re: Error importing fetching key from wkd

[Todd Zullinger via Gnupg-users]

Konstantin Ryabitsev via Gnupg-users wrote:
> FYI, I also provide gnupg22-static and gnupg23-static packages that can be
> rebuilt and installed on RHEL 7+ (though I haven't tried on RHEL9):
> 
> https://copr.fedorainfracloud.org/coprs/icon/lfit/packages/
> 
> They install into /opt and can be used directly as /opt/gnupg22/bin/gpg (and
> others).

Thanks Konstantin!

On EL8/9, I needed to disable the debugsource packages for a
sucessful build:

%define _debugsource_template %{nil}

I only tested builds of gnupg23-static on EL8/9, but the
gnupg22-static package looks like it would need the same
treatment.

Of course, the difference in algorithm support between
upstream and EL8/9 is much smaller than it was on EL7.
(Here's to seeing the differences disappear entirely.)

-- 
Todd


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

Re: Error importing fetching key from wkd

[Todd Zullinger via Gnupg-users]

Hello again,

I wrote:
> Dirk Gottschalk via Gnupg-users wrote:
>> A workaround for this is to download the SRPM, remove the
>> line '--disable-brainpool' and rebuild the package.
> 
> Ahh, excellent.  That's a relatively recent change.  It's
> available in the Fedora (and RHEL) libgcrypt-1.10 packages
> which I believe are only in the freshly released Fedora 36
> and RHEL 9.

For the future, you can now rebuild the libgcrypt rpm from
Fedora 36 with brainpool support without having to edit the
spec file manually¹.  You can pass `--with brainpool` to the
rpmbuild command, e.g.:

rpmbuild -rb --with brainbpool /path/to/libcgrypt.src.rpm

Hopefully that makes life just a little easier for folks
using Fedora who want or need brainpool support.

¹ https://src.fedoraproject.org/rpms/libgcrypt/c/6571417ff

-- 
Todd


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

Re: Error importing fetching key from wkd

[Todd Zullinger via Gnupg-users]

Hi,

Dirk Gottschalk via Gnupg-users wrote:
> A workaround for this is to download the SRPM, remove the
> line '--disable-brainpool' and rebuild the package.

Ahh, excellent.  That's a relatively recent change.  It's
available in the Fedora (and RHEL) libgcrypt-1.10 packages
which I believe are only in the freshly released Fedora 36
and RHEL 9.

Previous releases contained a 'hobbled' libgcrypt tarball
where the brainpool curves were removed entirely.  (That's
the usual practice for items which cannot be included for
legal reasons.)

It's good to see things are moving in the right direction,
at least.

-- 
Todd


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

Re: Error importing fetching key from wkd

[Todd Zullinger via Gnupg-users]

Hi,

Werner Koch via Gnupg-users wrote:
> On Wed, 25 May 2022 22:58, Dirk Gottschalk said:
> 
>> $ gpg --with-colons --list-config curve
>> cfg:curve:cv25519;ed25519;cv448;ed448;nistp256;nistp384;nistp521;secp25
>> 6k1
> 
> This should read
> 
> cfg:curve:cv25519;ed25519;cv448;ed448;nistp256;nistp384;nistp521;brainpoolP256r1;brainpoolP384r1;brainpoolP512r1;secp256k1
> 
> Note the Brainpool curves.  Seems that Redhat still patches them out of
> libgcrypt.

The question of whether these curves can be kept in Fedora
was brought up on the fedora-legal list some time ago.  The
most recent status update¹ from Fedora Project Leader
Matthew Miller on January 28, 2022 says:

So, these things move slowly, but this _is_ being
worked on. I'll let you know when I can.

That sounds midly hopeful.  With luck, the curves will be
cleared for inclusion (at least eventually, even it not
terribly soon).

¹ 
https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/message/3ESF4KDVMLQPZX4H2S4L7BP5BHJPMPMB/

-- 
Todd


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

Re: Odd error

[Todd Zullinger via Gnupg-users]

Hi,

Werner Koch wrote:
> I looked at the Fedora Libgcrypt source and noticed that they ship
> libgcrypt with the nistp192 and all brainpool curves removed.  I have
> not yet build this version but given that one of your keys has brainpool
> curves this might be the culprit.
> 
> I can understand that they remove nistp192 for security policy reasons.
> But I do not understand why the brainpool curves are removed.  The
> general statement in the spec file is that curves need to be removed due
> to patent rasons.  However, Brainpool curves are less prone to patent
> claims for fast multiplication than the NIST curves and we actually use
> the very same code for all those Weierstrass curves. 

FWIW, I noticed that someone recently asked about the status
of the ECC Brainpool curves on the Fedora Legal list:

https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/WUQNAB4EPWSJMMVECL2TZGKB5KIDESII/

With luck, a fresh review by the Red Hat legal folks will
result in those curves becoming accessible in the Fedora
libgcrypt packages.

Cheers,

-- 
Todd

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

Re: setrlimit failure on aarch64 (was: Interesting failure on aarch64)

[Todd Zullinger via Gnupg-users]

Werner Koch via Gnupg-users wrote:
> On Fri, 20 Dec 2019 11:22, Konstantin Ryabitsev said:
> 
>> On x86_64 this succeeds, but when I tried building on aarch64, that step 
> [...]
>>   gpg: Fatal: can't disable core dumps: Operation not permitted
> 
> setrlimit returns an unexpected error code:
> 
> if (getrlimit (RLIMIT_CORE, ))
>   limit.rlim_max = 0;
> limit.rlim_cur = 0;
> if( !setrlimit (RLIMIT_CORE, ) )
>   return 0;
> if( errno != EINVAL && errno != ENOSYS )
>   log_fatal (_("can't disable core dumps: %s\n"), strerror(errno) );
> 
> This is the first time I see a report that EPERM is returned.

The getrlimit call also fails, according to strace:

getrlimit(RLIMIT_CORE, 0xeb2acf88)  = -1 EPERM (Operation not permitted)
setrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=0}) = -1 EPERM (Operation not 
permitted)

I don't have access to an aarch64 host running RHEL 7
directly, so my only testing is via the mock command from an
aarch74 Fedora 31 host.

Mock can use two styles of container, an old-style chroot or
new-style systemd-nspawn.  Using chroot succeeds, while
systemd-nspawn fails.

I tested with CAP_SYS_RESOURCE added to the capability list
in the systemd-nspawn call, without success.  From my
reading, that should work (thought shouldn't be needed as
we're not trying to raise the limit).

So it seems like a bug either in systemd-nspawn or a lower
level component like glibc or the kernel with RHEL 7 on
aarch64, as you suggested.

-- 
Todd


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

Re: Interesting failure on aarch64

[Todd Zullinger via Gnupg-users]

Hi Konstantin,

Konstantin Ryabitsev wrote:
> I came across an interesting gpg failure while trying to build 
> git-2.24.1 RPM for Fedora COPR. As part of RPM build, the prep stage 
> attempts to verify the tarball signature using Junio's PGP key:
> 
>   %prep
>   # Verify GPG signatures
>   gpghome="$(mktemp -qd)" # Ensure we don't use any existing gpg keyrings
>   # Convert the ascii-armored key to binary
>   # (use --yes to ensure an existing dearmored key is overwritten)
>   gpg2 --homedir "$gpghome" --dearmor --quiet --yes %{SOURCE9}
>   xz -dc %{SOURCE0} | # Upstream signs the uncompressed tarballs
> gpgv2 --homedir "$gpghome" --quiet --keyring %{SOURCE9}.gpg 
> %{SOURCE1} -
>   rm -rf "$gpghome" # Cleanup tmp gpg home dir
> 
> On x86_64 this succeeds, but when I tried building on aarch64, that step 
> returned the following error:
> 
>   Building for target aarch64
>   Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.FYxOmt
>   + umask 022
>   + cd /builddir/build/BUILD
>   ++ mktemp -qd
>   + gpghome=/tmp/tmp.dndOuot6S2
>   + gpg2 --homedir /tmp/tmp.dndOuot6S2 --dearmor --quiet --yes 
> /builddir/build/SOURCES/gpgkey-junio.asc
>   gpg: Fatal: can't disable core dumps: Operation not permitted
>   error: Bad exit status from /var/tmp/rpm-tmp.FYxOmt (%prep)
[...]
> I'm curious what exactly is at fault here -- is there something in the 
> COPR build environment that causes this error, or is there something 
> that gnupg is not checking correctly?

I noticed this recently as well.  It only happens on EPEL-7
aarch64, which has gnupg2-2.0.22-5.el7_5.  Builds for EPEL-8
aarch64 work fine.

I've tested this on one of the Fedora package maintainer
aarch64 instances as well and it fails there too.  That
doesn't narrow it down much, other than likely ruling out
something specific to the COPR build environment.

It could still be a bug in gnupg-2.0.22, in the RHEL-7
packages (gnupg2 or otherwise), or when used with mock on
aarch64. For those unfamiliar, mock is a Fedora/EPEL rpm
build tool.

-- 
Todd


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