This has been fixed some time ago when the UI for generating OpenPGP keys was rewritten.

In T2671#158357, @werner wrote:

It seems that editing a pre-created revocation certificate on Windows with Notepad doesn't let Kleopatra detect this correctly as OpenPGP file and thus refuses to import. Works on the command line but needs more testing.

I don't see why this would be a Kleopatra issue. How is Kleopatra supposed to know that "mytestfile.txt (002)" isn't the original filename, but just the result of another program that's too stupid to properly resolve filename conflicts?

Another idea would be a gpgconf daemon that answers all queries from its in-memory cache. Obviously, this wouldn't help with the very first start unless the daemon is started automatically on login which should probably be default behavior at least on Windows anyway. OTOH, gpgme does already cache the config so this would only have an effect when starting Kleopatra.

If the keys on the smart card are already known to Kleopatra/GnuPG (which should be the case if the smart card was inserted when Kleopatra was started), then on import of the corresponding public key Kleopatra now asks whether the certificate is the user's certificate (instead of asking whether they want to certify it).

For this I think a better solution might be if we would remove keys that are already in a group from the list of "available" keys.
By this I mean that if you edit a group and move keys down then they should be removed from the upper list of available keys so that it is easily visible which keys in your keyring are not part of a specific group.

done

This is now ready for testing. The import result dialog and the import error dialog now have an additional "Show Audit Log" button.

Well, the modern way, recommended by the FSFE, for license notices in source files is SPDX instead of verbose license notices. https://reuse.software/

Closing. Not a bug in pinentry. The user ID of the key is encoded incorrectly and pinentry just displays the incorrectly encoded user ID.

It's irrelevant whether you can trick the combination of gpg and PowerShell to show the wrong encoded user ID correctly. The user ID is still encoded wrongly and every standard-compliant implementation of OpenPGP will show garbage when displaying the user ID.

Looking at the hexdump of the user ID in the exported (and dearmored) public key this looks like a classic double-encoding problem, i.e. UTF-8 encoded UTF-8:

42 6A C3 83 C2 B8 72 6E
      ^^^^^^^^^^^

This is now ready for testing.

https://gpg4win.org/download.html, but there isn't a Gpg4win release with GnuPG 2.2.29. The most recent Gpg4win 3.x has GnuPG 2.2.28. (All releases of Gpg4win 4.x include GnuPG 2.3.x.)

On Linux, I also get garbled output for your key:

$ gpg --show-key <bbs_gpg.public.pgp 
pub   rsa4096/67BDA85044042E3B 2022-11-06 [SC]
      0F20E48DEA9FD7A5626DBA0067BDA85044042E3B
uid                            Bjørn Bouet Smith <bjornsmith@gmail.com>
sub   rsa4096/08D7C29E12A34AD2 2022-11-06 [E]

This indicates that the user ID was encoded incorrectly by the gpg included in git when you created the key.

How did you generate the key? On the command line? Which command line did you use? Can you attach the public key to this report?

To test this you need a key with a subkey (including the primary key) that is marked for signing and authentication, but not for encryption. Open the Subkey dialog, insert an OpenPGP smart card, right-click this subkey and select Transfer to card. Select the Authentication slot when you are asked which card slot the key should be written to.

[CMS]
AllowSigning=false

hides the S/MIME-Sign... entry in the Clipboard menu (in the Tools menu and the context menu of the system tray icon).