My test case is to import my pubkey and then run:

We don't support v3 keys at all.

Fix was released with GPGME 1.10.0

I need to look closer at some details. However it seems that because your default-key has no valid encryption key, --default-recipient-self tells gpg to encrypt to the first usable key in the keyring. This is clearly a bug.

Please add -v to all gpg invocations to increase the verbosity. I would also like to see your gpg.conf.

(BTW, --create is not an option - you meant --encrypt)

That is not easy to fix in a shell script. I would prefer to get rid of gpg-zip or make it a simple wrapper around gpgtar like

New cards will come with a fix. I am not sure whether a production run has yet been done, though.

About Debian: Stable releases are only updated for bug fixes and not for new features. This is an important for almost all production systems. Rolling release distros do not provide a platform which can be used to replicate use cases or problems.

Fixed. But you need to wait at least 4 seconds even with a 2 seconds ttl. Will go in 2.2.6 in about 3 weeks. Thanks for reporting.

Well, if you have access to the user's memory you are lost anyway. Should be fixed, though.

This seems to be the relevant part of the log:

2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card inactive/removed
2017-11-18 07:45:15 scdaemon[8918] ccid open error: skip
2017-11-18 07:45:15 scdaemon[8918] pcsc_establish_context failed: no service (0x8010001d)
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: interrupt callback 0
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card removed

This has also the advantage that we could list the possible curves and let the user select them.

So should we revert this patch and replace it by an explicit command to switch the card to ECC?

Ben, can you please use a more descriptive subject for the commits. One of the reasons is that our jabber bot at gnupg-devel at conference dot jabber.gnupg.org shows just the subject and that is not really informative.

I close this bug as wontfix. If you can provide the requested changes for libtool please re-open this bug.

That will be the IP of proxy.x.com - the log shows that it finds that. But the log also shows that it can't find the address for the other names. "No Name" is EAI_NONAME.

Well, if your proxy inhibits GnuPG to retrieve information about the keyservers, GnuPG can't do anything about it.

Debugging network problems is always hard and applications should not include tcpdump facilities. Right, I consider TLS network failures identical to layer 3 network failures because we should assume that all traffic is encrypted. Wrong certificates are also a severe network failure much like wrong voltage levels at layer one ;-).