Fixed with: https://commits.kde.org/libkleo/245eff174331c49264d1248c529e0276e02e9e29

Thanks for the report. Indeed I can also reproduce it with my own key. For signatures from expired / revoked / disabled keys it shows "No public key" because GnuPG returns the same error in that case. We can fix that by looking up the key ourself.

By installation from version 2.3 an error occurred, I´ll send you a screenshot by e-mail. However, I have some comments to the current version which may also help: I have three keys, two on smart cards and one on a Yubikey. So long as only smart cards are used, it is no problem to change between the cards and they work fine. Problems occur, if a Yubikey comes in. (i) Not always a Yubikey is recognized by pressing F5. (ii) It the Yubikey is recognized and next a key from a smart card is needed, a computer restart is required.
I tried also command: gpgconf --kill gpg-agent
It was possible to change from smart card to Yubikey with the command. However, if the Yubikey 5 NFC was recognized, the only way to change back to the smart card was a restart of the computer.

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

Dear Andre, LO team is not able to integrate your fix unless a new release of GPGme is ready. Usually you do that every half year or so, but sometimes the delay is much less (e.g. 1.11.0 and 1.11.1). Perhaps, you would find it possible to roll out a minor version of 1.13.0 to ease the suffering of international users a bit earlier?

@sapienza Can you try it with Kleopatra please and if it fails there, too please post the "Diagnostics" from Kleopatra. (See "Blocco note" in Kleopatra for the same functionality)

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.

Anglocentrism smells like a relic discrimination in our age of Unicode, let users name folders as they natively see the world. For example, a Greek/Russian/Turkish carpenter with calloused hands, who stores his chisel and hammer in a toolbox, might want to store computer tools like GPG or LibreOffice in a folder Εργαλεία/Инструменты/Araçlar (=Tools), but particular tool unexpectedly says “Error!”, which might be perceived as passive-aggressive “No, I was made to serve the needs of English-speaking celestials only”. Thanks to Andre Heinecke and Egor Pugin for sympathetic attitude and prompt steps to solve this issue.

Looks good, thanks!
I think they (LO) will catch up with the next gpg4win or gpgme release or smth like that.

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.

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.

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.

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.

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

No more reports about this in a while.

Fixed with 3.1.7

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