Well, I can narrow the root case. A Yubikey 5 was successfull installed and can be used. Then I started to test the OpenPGP card. I recognized, that by pressing F5 in Kleopatara a change between YubiKey and Smart Card happens. However, if I test it via command line, Yubikey does not change, although it is dismounted and the smart card is inserted. Probably therefore, the private key cannot be found. It should be mentioned that I have a computer with integrated smart card reader. First I configured the card, then the Yubikey. I started to test the Yubikey first. Therefore, I believe it is a mess in detection of smart card / Yubikey if used parallel.

Which one version gcc 9 you've been using?
May I see gcc -v ?

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.”

BTW: fedora corp provides already free access to build envs with gcc 9 which can be easily integrated with CIs.

What you mean " it is not reproducible for u"?
Did you try to use gcc 9 and you had no problems compiling gnupg or you don't have access to build env with gcc 9?
Try to google to "gcc 9 pragma" and you will find several discussions and patches done by people fixing similar issues.

@kloczek , it is not reproducible for us, so, we consider it may be a problem other than GnuPG itself, possibly, some specific build configuration parameter(s) for GCC, or something by unreleased code.
Please file a report with how to reproduce your problem.

• 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.

I did not yet implement the use of "key origin" in Enigmail. I don't believe that it adds much value, because I anyway need to track more details about autocrypt keys separately from the keyring (such as the peer-state).

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.

does the proposed mail value indicate that the key was received over e-mail, or is it intended to have some more nuanced semantics?

I disagree that it's conceptionally the same, unless you also consider any key on an HTTP server to be "conceptionally the same" as WKD.

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.

Certain origins do have special treatment but in general the key origin is meta data for the frontend.

I agree with you and GpgOL handles it that way so for me this would work. But I'm not actually implementing autocrypt, so I also added @patrick to the subscribers.
I've talked about using key-origin in Enigmail with him in Brussels and I would be interested what he thinks Enigmail might require and if gpg could be improved for that.

Why do you think that it is gcc bug?

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.

Hi,
if I don't misunderstand you, we already have that:

My interpretation of the key-origin is that it's basically up to the application what it does with the information. It is added information, like the TOFU history we can have. I don't necessarily think in terms of "trustworthyness".

I'm a bit confused. The origin of Autocrypt keys is clearly different from keyservers ("ks"), why would they use the same value? I was aware that origin values are mapped to integers, but your description seems to imply that these integers have significant ordering in terms of trust. The documentation in the man page is a bit bare bones, but my interpretation of "key-origin" was that it simply stated the method of discovery for a key, leaving any implications of trust to the client. Is this incorrect?

@werner: what if the autocrypt header is in a dkim-signed message, and the dkim signature covers the autocrypt header, and the dkim signature is verifiable using dnssec? is it still the same as from a keyserver?

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.

This is largely solved.

I implemented support for ECC and DSA public keys in poldi. Tested with ECC (curve 25519) key on Gnuk smartcard (Nitrokey Start).

I think commit https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=09c27280cc09798d15369b3a143036b7ab5ddd69 should be backported to 1.8 branch of libgcrypt.

HTTP/1.1 spec, RFC 7230, Section 5.4, paragraph 2:
https://tools.ietf.org/html/rfc7230#section-5.4

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

It's up to GPG to send the Host header that shows the user's intent.

Here's an ugly hack to make this work (patch based on v2.2.15).

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:.

@werner
It is good practive to open a public ticket for many projects, because otherwise the XMPP users don't know if the fact is already known, reported or being worked on. Alternatively: Let us document the procedure in public what someone should do, if the xmpp server ist down or the certificate is expired. What is that procedure?

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

I gave the usual ping. Yes I'm note sure why it's not automated. Our jabber server is hosted by a volunteer so it is not in our hands.

As it ran out again before this issue got officially closed, I'll reopen it with an extended title.
Wasn't the idea to automate this somehow? >:)