Modern way for license notice seems use of URL: https://www.gnu.org/prep/maintain/maintain.html#License-Notices-for-Code
https://www.gnu.org/licenses/gpl-howto.html

works

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

@ametzler1 Thanks a lot for your help.

Something like this?

Any comments on applying these to gnupg-2.2?

In T6288#165435, @werner wrote:

Bootstrapping is an issue. Recall that pkg-config is not a simple program but requires the use of glib (which depends on libffi, libmount, libpcre) - catch-22. Makes building GnuPG on AIX not actually easy.

Bootstrapping is an issue. Recall that pkg-config is not a simple program but requires the use of glib (which depends on libffi, libmount, libpcre) - catch-22. Makes building GnuPG on AIX not actually easy.

FWIW I would vote for a) "document gpgrt-config in detail" and suggest using pkg-config (variant) for direct invokations. There seems to be little benefit in investing effort/complicating gpgrt-config when pkg-config works fine.

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.

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.

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

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

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]

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

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.

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.

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

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]

This is the key exported with:

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

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?

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

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 - gpgwin is no better:

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?

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.

Sorry, it looks like no problem.

Implications are... you won't be possible to use new protocols introduced by newer OpenSSH:

Thanks. Adding 'PubkeyAuthentication unbound' to my ~/.ssh/config seems to workaround it for me on openssh-9.1p1-3 (arch). I don't quite follow what the implications of that setting are though.

Thank you for the bug report and your suggestion.

In my cases (tested with 9.1), here are the length of data to be signed by ssh-agent (emulation by gpg-agent).

• 164 bytes: Both features disabled by: ssh -o KexAlgorithms=-sntrup761x25519-sha512@openssh.com -o PubkeyAuthentication=unbound
• 192 bytes: Unbound only by: ssh -o PubkeyAuthentication=unbound
• 298 bytes: No Post Quantum only by: ssh -o KexAlgorithms=-sntrup761x25519-sha512@openssh.com
• 330 bytes: Both features enabled (no options)

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.

Actually we have two gpgme versions in gpg4win because gnupg is a "sub"-installer inside of gpg4win and it comes with its own gpgme. That gpgme is the release version but the one used by gpg4win's kleopatra is often a newer snapshot.

Here is the patch which will go into the next release

From f61a5ea4e0f6a80fd4b28ef0174bee77793cf070 Mon Sep 17 00:00:00 2001
From: Werner Koch <wk@gnupg.org>
Date: Tue, 22 Nov 2022 16:36:46 +0100
Subject: [PATCH] Fix an integer overflow in the CRL signature parser.

ok, works as described.

thank you, works for me.