Fwiw we're tracking this downstream as "dev-libs/libgcrypt-1.7.0: impossible
constraints on 'asm' operand" - https://bugs.gentoo.org/show_bug.cgi?id=580270

I'm not sure, if it is relevant, but
I tried to build the newer version, the v2.1.11, id est the "GnuPG Modern"
and it did not go so well either, despite the fact that
I custom-built the dependent libraries and put their bin folders to
PATH and lib64 folders LD_LIBRARY_PATH prior to attempting
to build the gnupg.

Thanks for the explanation, Werner.

This note might also be worth adding to the gpg-preset-passphrase manpage.

Here is the gist of the info:

i686-pc-linux-gnu
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. \

-I../src -I../src -I/usr/local/include -g -O2 \
-fvisibility=hidden -Wall -MT rijndael-aesni.lo \
-MD -MP -MF .deps/rijndael-aesni.Tpo -c rijndael-aesni.c \
-fPIC -DPIC -o .libsrijndael-aesni.o

rijndael-aesni.c: In function '_gcry_aes_aesni_ctr_enc':
rijndael-aesni.c:817:3: error: can't find a register in class \

'GENERAL_REGS' while reloading 'asm'

rijndael-aesni.c:1117:3: error: 'asm' operand has impossible constraints
rijndael-aesni.c:817:3: error: 'asm' operand has impossible constraints

gpg1 does not known about keygrips. Instead of the keygrip, gpg1 uses the
fingerprint as cacheid for gpg-agent. The agent's command GET_PASSPHRAE, as
used by gpg1, uses a different cache mode from what gpg-preset-passphrases uses.
Thus even if you replace the keygrip with the fingerprint of the (sub)key, it
won't work.

I'll add

Note, that the tool @command{gpg-preset-passphrase}, which comes
with GnuPG-2, cannot be used to preset a passphrase for this
version of GnuPG.

to the gpg 1 man page.

Thank you. I've attached the output from 'ldd tests/fdpassing'. Not sure how to
read it.

I've attached the config.log file.

I'm reading the implementation of new libusb.
If I guess correctly, the picture of the problem would be:

• New libusb somehow caches (or uses cache of kernel's) USB device list structures.
• When the device is plugged off/on (or hardware failures), the cache should be

updated.

• GnuPG's ccid-driver possibly keeps using staled data of USB device list.

I'll check the implementation detail, and try fixing this.
I think that current ccid-driver with new libusb has an issue for memory leaks
for device list, so, it should be reviewed and modified anyway.

It would be good if we could have a reproducible scenario.

There's an issue somewhere: I built & installed libgpg-error 1.22 beta exactly
the same way as I did with 1.21. I'm not surprised by your answer: you guys have
already dismissed another perfectly valid issue report.

I already sent Justsus some code I started with to restore that feature.

Fixed in f8adf1a.

Thanks for looking into this, Justus.

While you're working on this, it might make sense to consider restoration of the
--export-options export-reset-subkey-passwd flag, which was dropped in 2.1.

This flag was used by at least one GnuPG downstream (monkeysphere); its absence
causes "monkeysphere subkey-to-ssh-agent" to fail.

In GnuPG 1.4.x and 2.0.x, the option was defined this way:

export-reset-subkey-passwd
       When  using  the  --export-secret-subkeys  command,  this
       option resets the passphrases for all exported subkeys to
       empty. This is useful when the exported subkey is  to  be
       used  on an unattended machine where a passphrase doesn't
       necessarily make sense. Defaults to no.

Related T2324.

Werner: Yes please.

Something went wrong wile you installed libgpg-error. The linker picks up
another version of the library. If you need help, please ask on gnupg-devel.
Glad, that it now works for you.

DoS via Tor - sorry.

pushed to the 1.7 branch.

I have some stashed work to fix this but it is not ready - let me know if you
want to work on it.

Thanks for the info and the patch.
I have pushed commit 4545372 to master and it will eventually go into 1.7.1.

commit d02de6c should fix that.

Use '=' for an exact match and optionally '*' for a substring match.

*See also T2070

Hi Werner,

FreeBSD 9.x uses gcc version 4.2.1 20070831 patched [FreeBSD]

See also issue20170

Thanks for the patch.
Which compiler version are you using?

Please provide more information. A kernel version is not sufficient. What
distro are you using, which compiler, etc. Sending the file config.log or a
transscript of the configure run would be helpful.

Please describe the interaction. IIUC, isn't it pinentry problem?
Did you input your PIN? For "2 - unblock PIN" operation, you need to
authenticate as admin, did you input your PIN for admin? Wasn't it a failure of
PIN input for admin or user, whatever?

libgcrypt 1.7.0 is out. Please test with it.

D365: 816_patch-cipher_crc-intel-pclmul.c

The following patch solves the problem.

Ok, so there are two problems:

1. gpg --batch should not use the pinentry mechanism at all.
2. gpg --export-secret-key should export unprotected keys that are stored w/o a

passphrase.

Werner, I started patching gpg-agent to allow 2., but gpg does only accept
protected keys from gpg-agent in export.c's transfer_format_to_openpgp. Is that
by design or simply not yet implemented?

I don't have a test setup for that. Kleopatra currently polls gpg-agent if a
smartcard is available.

According to Gniibe this might be causing this problem. I'm planning to change
that to switch to looking for readerstatus files that are created when a
smartcard becomes known. But this still might cause the smartcard to be locked
by scdaemon? I'm not sure.

HKPS won't be the reason, we use plain HKP

as of gpg.conf
keyserver hkp://keyserver.int.myCompany.com:11371

BTW. The versions in the previous post should have been 2.0.28 and 2.0.30 vs.
2.1.11, of course.

Hello. If you are using https to talk to your keyserver, your problem might be
Issue 1950 which we fixed in GnuPG 2.1.10.

I don't think the bugs are necessarily related. Your issue looks like you build
your own libgpg-error and linked fdpassing against that, but your runtime linker
uses your system-supplied libgpg-error. Try running 'ldd tests/fdpassing' to
see which libgpg-error is used at run-time. Feel free to ask if you need more
assistance.

Hello,

please run:

  strace -f -E srcdir=tests -o fdpassing.strace tests/fdpassing

and attach fdpassing.strace to this bug report.

I've now also mentioned that the current one is used since April 2016 and listed
the previous certificates.

Andre, we probably should also list the old certificate, because we still have
files out there with it.

Like, until 2.3.0 the codesigning certificate was: ..

For completeness, this are the pages:
https://www.gpg4win.de/package-integrity-de.html
https://www.gpg4win.de/package-integrity.html

Indeed, thanks for the report, I've updated the information for our new
certificate that we've used for 2.3.1

Sorry for the confusion caused by missing that in the first place.

System is Linux 3.2.0-23-generic.

GnstheGrain,

hmmm. :/

Thanks for the report.

A collegue of mine now has a similar problem with GnuPG on MacOS during gpg
--refesh-keys from an in-house SKS keyserver (set in gpg.conf)

Happens with GnuPG 2.2.28 and GnuPG 2.2.30. Problem disappeared with GnuPG 2.1.11.
Hence changed category back to gnupg as it's no Windows-only problem anymore.
Still assume that it is somewhat related to larger key rings.

gpg: Total number processed: 392
gpg: unchanged: 392
gpg: keyserver communications error: Not found
gpg: keyserver communications error: Bad public key
gpg: keyserver refresh failed: Bad public key

Duplicate of T2318