Page MenuHome GnuPG

Pinentry garbles international characters
Closed, InvalidPublic

Description

When using GPG on windows to sign git commits by adding the following git config:

[commit]

gpgsign = true

[gpg]

program = "C:\\Program Files\\Git\\usr\\bin\\gpg.exe"

The every time I get asked to enter my password for the key I am using I am presented with the following dialog where my name is garbled.

By contrast when I open up a command line and type in

C:\Program Files\Git\usr\bin> .\gpg.exe -k
/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]

My name turns out as expected

GPG info:

gpg (GnuPG) 2.2.29-unknown
libgcrypt 1.9.3-unknown
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /c/Users/bbs/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

So to me it seems like that whatever creates the pinentry dialog assumes ASCII or another character set.

I am using the GPG that comes with the git installation.

Details

Version
2.2.29

Event Timeline

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.

werner claimed this task.
werner edited projects, added Support, gpg4win; removed Bug Report.

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?

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

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.

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.

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