Minor

We will do a new release in two or three weeks.

Can you please run claws like this:

Did you encrypt to a key of yours? You can only decrypt if you have the matching secret key for the public key you used for encryption. The error message: "No secret key" should be obvious.

Reolved since summer last year.

I don't anymore think this is a high priority request. BTW, A more real problem than several dirmngr instances is multi-user access to smartcards.

We do not support 64 bit Windows thus this problem on Cygwin is obvious. Funny that Cygwin falls back to native Windows object in this case.

And please do not use Gpg4win 3.16 but the bug fixed release 3.1.7.

Please explain in detail what you did to receive this error message.

@gniibe already wrote: “With gcc-9 in Debian experimental, everything goes well.”

• If the original key origin is a KEYSERVER or WKD it is fine to fetch an update of the key from a keyserver/wkd without user interaction.
• if the key origin is file it can be assumed that the key has bee received hand to hand and thus the existence of that key should not be made public.

I did lot of tests in the last weeks while working on gpg-card.

Well, it took long to fix. My original plan was to fix it while reworking getkey.c but that I have not yet come to work on that.

Conceptionally it is the same. You receive a key and start to use it, everything else is not a matter of gpg; in particular not the autocrypt protocol.

So this seems to be a gcc bug, right. Then we should close this bug.

autocrypt is not different from attaching a file to a (signed) message as it has always been done. We have no special treatment for that in gpg. Certain origins do have special treatment but in general the key origin is meta data for the frontend. For example it allows us to update a key received from WKD when it has expired.

Receiving a key by mail should in general be considered unknown and is not more trustworthy than receiving a key from a keyserver. I would suggest that you use "ks-pref" for this purpose. That origin value has no special meaning in gnupg but is numerical ordered between keyserver and and DANE; gpgme currently maps it to keyserver level anyway.

Please be so kind and point me to the specs stating that you should put the IP address into Host:

So in short you want:

1. Allow to specify a keyserver by IP without any DNS lookups.
2. When connecting via IP use the IP address for Host:.

Right, no need to open a ticket. Jens has no account here anyway.

Good that it works again for you.

I don't anymore think that it makes sense to fix it. Further there is no cache for PINs; that is entirely up to the card.

BTW in 2.2.15 you can also do

Actually you should never use --debug-all; we have more specific log levels. Use --debug help to see them.

News for 1.13.0:

• Support GPGME_AUDITLOG_DIAG for gpgsm. [T4426]

The reason for the problem is that we check all configured keys to print a note about expired and otherwise unusable keys. This should be warnings but due to the way we use shared code the error counter is bumped and operations stops. With the fix these will just be warnings and decryption continues.

Can you please run

gpg --debug ipc -vK

which will also start gpg-agent and print some diagnostics. You may want to redact the output. You can also run

gpg-agent -v --daemon

which should also print some more info.