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.

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.

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

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.

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.

Why do you think that it is gcc bug?

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

This is largely solved.

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.

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

With the downstream report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925952 I resolve this here.

Thanks for the report. This was fixed with: https://cgit.kde.org/libkleo.git/commit/?id=8a94ac0835f0cff8908943d2a630a003a3429220 which I backported to Applications 18.12 which is the current stable release. But debian needs to add this patch. I'll report a debian bug and link it here.

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.

This was most likely a (chipcard) hardware issue. It went away after polishing the contact pads for a bit. Possibly my laptop reader applies more force...

No more reports about this in a while.

False positives happen from time to time with various Anti Virus Software. We have it as a FAQ in the wiki:
https://wiki.gnupg.org/Gpg4win/AntiVirusSoftware

Thanks so much your helps.
With new version 3.1.6, I can generate key on Kleopatra tool and use key stored in smartcard.

The same chipcard works still fine in a different (type of) reader / machine.

Thanks people, thanks aheinecke, for your support.

3.1.6 is released. Please test again and reopen this issue if you still have problems.
Thanks!

3.1.6 is released.

3.1.6 is released.

3.1.6 is released.

gpg4win 3.1.6 is released which contains this fix.

3.1.6 is released please use that one.

3.1.6 is released

Sorry, this did not make it into 3.1.6. But I'll definitely see about it for the next release. If it is an institutional / corporate issue you could also contract us through www.gnupg.com

Strangely, if I look at my upgrade history, it cannot be caused by gnupg or libusb update. Everything was working fine in February 2019.

I think I found it. The problem was that for mails without headers the S/MIME detection would fail and the mails would still be handled by GpgOL. I think this together with the fixes for T4403 / T4267 should finally solve this with Gpg4win-3.1.6

BTW in 2.2.15 you can also do

I forgot: Instead of importing the missing internal CA, this works:

I agree, the question is which CRL is checked when how. Maybe there is some mistake on my side. Here is a recipe for Debian:

I don't think this is a bug. Failure to encrypt when CRL check fails is expected.

In T4427#123774, @werner wrote:

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

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

From: aheinecke (Andre Heinecke)
Sent: Montag, 28. Januar 2019 19:25

fwiw. Your patch is beautiful in which it follows our coding style and
debug output. I'm confident that we will accept it but currently I have
to read up on Job's a bit.

Is there a way I could help you with this? This issue is hampering adoption
of GnuPG 2 here.

--

Jan Echternach

Many thanks for the fast fix! Decryption works now. I'll report another bug for encryption.

Trying to install the update manually (according to windows update my windows is fully updated) it says "This update is not meant for your computer" and aborts.

I've started some documentation how to repair a broken archive under: https://wiki.gnupg.org/TroubleShooting#Restoring_corrupted_Archives_created_by_Kleopatra

A quick note: The second workaround above does not work.
The presence or absence of the expired certificate in my keyring does not matter. The check by dirmngr fails regardless.

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.

@nbriggs No this is not related if you get "no pinentry" it means pinentry is not started at all. This issue is about pinentry starting but not properly coming to the foreground. I've opened T4430 for your issue.