You are using the basic pinnentry which comes as part of the basic installer. Almost everyone does not use this but Gpg4win which has a real pinentry. See http://gpg4win.org You don;t need the program statement then because gpg is installed in the PATH.

So because I use some thing that "almost everyone does not use" - but something that you distribute you do not even want to fix it?

How about you then just remove pinentry from the basic installer, if its broken and you do not intend to fix it?

Also - gpgwin is no better:

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?

Also, please try if generating the key with Kleopatra/Gpg4win helps. I have just created a key with an 'ø' in the name with Kleopatra and the letter was shown correctly in Kleopatra and by gpg (2.3.9) in a PowerShell window.

It seems like gpgwin generates keys where the name are not compatible with each other.

use "Bjørn Bouet Smith" as name using the command like (my old version) Name is still garpled in gpgwin. Generate a new key inside gpgwin, name show up correctly.

So it seems like a windows/command line incompatibility issue.

If I generate a new key using "Bjørn Bouet Smith" via the gpg.exe distributed with gpgwin, it shows up just fine in Kleopatra

In T6289#165411, @ikloecker wrote:

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?

Yes I generated the key with the command line version of the version that was provided with git - the version I mentioned in the initial report.
When I generate a key inside Kleopatra it works just fine, if I generate a key with the gpg that is included with gpgwin - it also show up correct.
So it seems like the version that is included with git either contain a bug, is built differently with poor support for internaltional characters.

This is the key exported with:

gpg.exe --output D:\bbs_gpg.public.pgp --armor --export bjornsmith@gmail.com

If I import the keys into gpgwin it shows up garbled - both in the console version of gpg.exe and Kleopatra, but if I run

gpg.exe -k

With the old gpg version it shows up as:

/c/Users/bbs/.gnupg/pubring.kbx
-------------------------------
pub   rsa4096 2022-11-06 [SC]
      0F20E48DEA9FD7A5626DBA0067BDA85044042E3B
uid           [ultimate] Bjørn Bouet Smith <bjornsmith@gmail.com>
sub   rsa4096 2022-11-06 [E]

I am not sure if the export is correct - or if you need something else?

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.

In T6289#165413, @bjornbouetsmith wrote:

So it seems like the version that is included with git either contain a bug, is built differently with poor support for internaltional characters.

Yes, seems so. In either case, there's nothing we can do anything about since the versions provided by us appear to work correctly.

Yes, seems so. In either case, there's nothing we can do anything about since the versions provided by us appear to work correctly.

But it is strange that the version can show the characters correctly - so it can encode and decode to the same output.

Is there any way I can find an "old" version of gpgwin that matches the version that came with git? So I can test if its something that was fixed in a version, or finally conclude that git's gpg version is broken - and if that is the case I need to raise a bug with them.

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

But you can find Windows installers of all GnuPG releases at
https://gnupg.org/ftp/gcrypt/binary/

okay, installed 2.2.29 and tried showkey:

C:\Users\bbs> gpg.exe --show-key D:\bbs_gpg.public.pgp
pub   rsa4096 2022-11-06 [SC]
      0F20E48DEA9FD7A5626DBA0067BDA85044042E3B
uid                      Bjørn Bouet Smith <bjornsmith@gmail.com>
sub   rsa4096 2022-11-06 [E]

And it shows as garbled - so I guess its a git compilation issue and not a gpg issue.

I do see this option:
--display-charset

And if I add that to the command:

C:\Users\bbs> gpg.exe --display-charset iso-8859-1 --show-key D:\bbs_gpg.public.pgp
pub   rsa4096 2022-11-06 [SC]
      0F20E48DEA9FD7A5626DBA0067BDA85044042E3B
uid                      Bjørn Bouet Smith <bjornsmith@gmail.com>
sub   rsa4096 2022-11-06 [E]

I get the "expected" result - so my guess is that the git version has either failed to detect the correct locale, like its supposed to do - or its hardcoded to iso-8859-1 - because it seems like the gpg.exe provided by gpg4win uses utf-8 either as default - or had detected that utf-8 should be used.

So perhaps something is off in the git compiled version.

thank you for the support and I guess we can just close the issue with that reason - and I will try to make an issue with git team instead

Just found out something weird - powershell tells me the default characterset is iso-8859-1
~~~
PS C:\Users\bbs> [System.Text.Encoding]::Default

IsSingleByte : True
BodyName : iso-8859-1
EncodingName : Western European (Windows)
HeaderName : Windows-1252
WebName : Windows-1252
WindowsCodePage : 1252
IsBrowserDisplay : True
IsBrowserSave : True
IsMailNewsDisplay : True
IsMailNewsSave : True
EncoderFallback : System.Text.InternalEncoderBestFitFallback
DecoderFallback : System.Text.InternalDecoderBestFitFallback
IsReadOnly : True
CodePage : 1252
~~~

So you could say that the git provided gpg detects the "correct" charset - but the official binary either detects "UTF-8" or is hardcoded to UTF-8.

But anyway - I created an issue with git for windows https://github.com/git-for-windows/git/issues/4137

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
      ^^^^^^^^^^^

Correctly encoded "Bjørn" looks like this:

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

Interestingly enough if I set LC_LCTYPE environment variable in powershell $env:LC_CTYPE = "C.UTF-8" - it behaves correctly and generates UTF-8 encoded names.

So I wonder if the official gpg have some kind of changed default characterset than what the git provided one does

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.