I've rewritten your patch a bit so that it falls more in line with our general style of helper functions and is more generic.

I've tested it with Gpg4win-3.1.7, too and it works for me so something must be special.

this error comes to me when I try to decrypt a message and I get this message

Unsupported protocol still means something with your GnuPG installation is strange.
Whats surprising me most here is that Kleopatra works for you.

I would be interested to here if it worked. But for now I'm closing this as resolved as there is no obvious next step.

As this task has no obvious next step I'm closing it.

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.

Well in general we don't support installation into UTF-16 paths for Gpg4win, our installer prevents that. This is probably why this issue never came up.

For what I use, please refer: https://tracker.debian.org/pkg/gcc-9

_gcry_fast_wipememory2 should be changed to always just use explicit_memset when available:

Thank you.

Thanks for the report and the patch. As this results in multiple message boxes (which we create and not Libreoffice) I'll assign it high priority.

Also see related libre office issue https://bugs.documentfoundation.org/show_bug.cgi?id=124609

I´ll give it a try for sure! Probaly next weekend, so my feedback will be sent next week. Please, keep the file open. THANKS

I'm interested if this works as you imagine with 2.3 I'm pretty sure werner worked on a problem like that.

Yep, I'd like that, too. Sadly G-Suite Sync does not support "PGP/MIME" which is the standardized format we need to put together a message with attachments in a Mail.
So for now we only have PGP/Inline support. See: T3545

I've looked into it alot first: If I use outlooks builtin S/MIME support it also does not work for me, at least over SMTP. I see the attachments but they have unknown type and if I double click them I get errors.

This was fixed afaik in 3.1.7 please let me know if this still does not work for you.

After re-start, the smart card will be recognized in proper way and it works. I assume it has something to do with using Yubikey and smart cards with different keys alternatively. The Yubikey was not found originally, so I modified the following:

2.3 Release plan is around this summer. There will be a public beta sooner.

Kleopatra recognizes the smart card, shows the correct version number and keys in the "smart card - management" window. In the Keylist I can´t find the key. Currently GnuPG 2.2.15 is installed. Do you know then version 2.3. will be released?

For Kleopatra there is a "TODO" to better handle multiple smartcard readers. E.g. that you can have mutliple tabs in the smartcard management view.

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.