[pkg-gnupg-maint] Bug#1108406: gnupg: On Debian 13, fail to import a secret key exported from a Debian 12 host

[Fred]

	Hello John,

Le dim. 29 juin 2025 00:52:31,
John Scott <jscott at posteo.net> a écrit :
> This is a good point Andreas made here. In general former releases of
> Debian were somewhat permissive other text encoding options, but only
> locales compatible with UTF-8 are supported by the GNU C Library and
> Debian lately. Your new machine is indeed set up to use UTF-8
> correctly based on the info in your original bug report, so that's
> good.

Yes, I use UTF-8 for some Debian releases, for me ISO-8859-1 is old and obsolete for a long time.
 
> Your log appears to use ISO-8859-1 to encode special characters, and
> the GnuPG log says this: gpg: DBG: chan_5 -> OPTION
> …

I was puzzled that my log was in this ISO-8859-1 encoding, and checking it, it appears it's my name attached to the key which is in this encoding… I generated this key a long time ago, indeed !!

> The "LC_CTYPE=C" is odd... My suspicion is that this causes a
> fallback to ISO-8859-1 (for input and output) when necessary because
> GnuPG has its own code to handle that encoding, and maybe GnuPG was
> thrown off by your terminal type as shown by 'ttytype=xterm-kitty'.

No, for the log record, I forced LC_ALL=C to get error messages in english and not in french, for better understanding ! But it doesn't work either with my default fr_FR.UTF-8 locale.

I tried something like :
env LC_ALL=fr_FR.iso88591 gpg -v --import cleComplete.gpg.asc
or
env LC_ALL=fr_FR.iso88591 gpg -v --pinentry-mode loopback --import cleComplete.gpg.asc
but the passphrase isn't recognized either.

> Also, the GNOME/GTK ecosystem deliberately only supports UTF-8 even
> if the system would normally use another encoding, so if GnuPG is
> trying to exchange ISO-8859-1 text with GNOME's Pinentry, that's
> always just wrong and GNOME Pinentry ought to make more noise about
> such an invalid configuration.
> 
> Here are my ideas:
> • What terminal emulator and desktop environment are you using? If
> you don't know, it's probably GNOME Terminal or the newer GNOME
> Console on GNOME. If it is indeed the Kitty terminal emulator, try a
> different one.

I have a Mate environment with i3wm, using kitty as default terminal. I tried running gpg import command from mate-terminal, but it doesn't work better.

> • Try to totally log out of your session or restart, and then try
> importing the key again passing the '--display-charset UTF-8' option.
> This should tell GnuPG not to make guesses but to use UTF-8 for both
> input and output.

I've rebooted meanwhile [for latest Debian 13 kernel update]…
Trying this didn't succeed :
gpg --import --import-options restore --display-charset UTF-8 cleComplete.gpg.asc

> • The easiest thing, however, might be to change your private key's
> password on your old computer to something with only US-ASCII
> characters, export *that* key, and import it on your new computer.
> The characters in US-ASCII are always encoded the same way in all
> encodings that might be at play, so this would allow for more
> forgiveness if the encoding is set wrong.

Note that my passphrase doesn't contain any locale specific character, only US-ASCII ones…

But perhaps all this problem only tell me it's time to change passphrase, or better generate a new key [using latest standards], and migrate to it :-)

I think this bug report should be kept in case other people has the same problem, but for my point, it could be closed or its severity decreased, as I'll going generating a new key…

  Thanks for your support :-)
	Fred.