Dear Maintainer,
I want to use my GnuPG key on a new laptop with Debian 13. I’ve exported my
key from my old computer using :
gpg --export-secret-keys --export-options backup --armor --output cleComplete.gpg.asc fredmob@free.fr
and copied that file cleComplete.gpg.asc on my new laptop, where I typed :
gpg --import cleComplete.gpg.asc
Here, gpg ask me for the key’s passphrase, but it doesn’t recognize it
(asking 3 times), and finally fail to import the secret key.
I tried also import with the option ’--pinentry-mode loopback’, typing the
passphrase in the terminal, but it doesn’t succeed either, with error
message : error sending to agent: Bad passphrase
I’ve tested the same file cleComplete.gpg.asc on another Debian 12 system,
and the importation succeeded on the first try.
With regards,
Fred.
Ahoy Frédéric, Thanks for your concise details. I have a couple thoughts. From this point after, make sure you use '--import-options restore' when you're doing the import on your new computer. That's probably not the cause of your problem here, but it does tell GnuPG it's okay to trust the detailed information that '--export-options backup' included. You can also use the '--debug-all' flag to make GnuPG print extra detailed information about what it's doing when it tries the import. If the time was not set correctly on your new computer yet that could also be the culprit, especially if it was on its first boot and it hadn't yet done much on the internet yet to sync itself. Also, would you be able to share your *public* key or say where it can be found? (Sending it as an attachment in a reply here with '--armor --export' would be great—make sure it's the *public* key however.) I haven't been able to find it from a quick search, but it could be an easy way to find clues. It could say a lot if there's any quirk with your key in particular. Speaking of which, I'd like to know if you can import your public key on the new machine. Thanks and I hope Trixie is otherwise going smoothly!
Hello John,
Thanks for your quick answer ! :-)
…
I've tried " gpg --import --import-options restore cleComplete.gpg.asc ", but without more success, the passphrase isn't recognized.
I've tried also, but the problem seems to be while verifying passphrase. Here is the traces in the attached debug.log file.
Yes, the new laptop is up and running from few days, no problem of time.
gpg --export --export-options backup --armor --output clePublique.gpg.asc fredmob@free.fr
(you'll find it attached to this email)
and importing on my Debian 13 laptop works :
$ env LC_ALL=C gpg --import --import-options restore clePublique.gpg.asc
gpg: key 5F8488C6624C8AB4: 2 signatures not checked due to missing keys
gpg: key 5F8488C6624C8AB4: public key "Fr�d�ric Boiteux <fboiteux@free.fr>" imported
gpg: Total number processed: 1
gpg: imported: 1
$ gpg -k
/home/fred/.gnupg/pubring.kbx
-----------------------------
pub rsa4096 2009-09-18 [SC]
81E284429071760F46AB03E15F8488C6624C8AB4
uid [ inconnue] Frédéric Boiteux <fboiteux@free.fr>
uid [ inconnue] Frédéric Boiteux <fboiteux@calistel.com>
uid [ inconnue] Frédéric Boiteux <fredmob@free.fr>
sub rsa4096 2009-09-18 [E]
$ gpg -K
$
I hope so !
Fred.
[...] [...] Hello Frédéric, is the locale setup identical on both the Debian 12 and 13 systems? (Check with the command locale without args.) Is the keyboard setup identical, are you really typing the correct string on the new system? Just to illustrate, both strings look identical but are not binary identical, just use you password instead of "Frédéric": ametzler@argenau:~$ locale | grep CTYPE LC_CTYPE="de_AT.UTF-8" ametzler@argenau:~$ cat <<EOF | sha1sum c92eb4d8bb529fc4e131e319705c07a44164a145 - ametzler@argenau:~$ locale | grep CTYPE LC_CTYPE="de_AT.iso88591" ametzler@argenau:~$ cat <<EOF | sha1sum 33fb0da4a9e7c75b5641c2d013abc703b2918a62 - cu Andreas
Andreas Metzler wrote: 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. Your log appears to use ISO-8859-1 to encode special characters, and the GnuPG log says this: gpg: DBG: chan_5 -> OPTION ttytype=xterm-kitty gpg: DBG: chan_5 <- OK gpg: DBG: chan_5 -> OPTION display=:0 gpg: DBG: chan_5 <- OK gpg: DBG: chan_5 -> OPTION xauthority=/home/fred/.Xauthority gpg: DBG: chan_5 <- OK gpg: DBG: chan_5 -> OPTION putenv=XDG_SESSION_TYPE=x11 gpg: DBG: chan_5 <- OK gpg: DBG: chan_5 -> OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus gpg: DBG: chan_5 <- OK gpg: DBG: chan_5 -> OPTION lc-ctype=C gpg: DBG: chan_5 <- OK gpg: DBG: chan_5 -> OPTION lc-messages=C 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'. 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. • 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. • 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.
Hello Andreas, Thanks for your suggestions / help. Le sam. 28 juin 2025 14:16:41, Andreas Metzler <ametzler@bebt.de> a écrit : Yes, it's a standard French setup, fr_FR.UTF-8. Yes, standard Bepo [« french » Dvorak] layout, on the 2 computers. Moreover, my passphrase doesn't contain locale specific characters, no accent… Regards, Fred.
Hello John, Le dim. 29 juin 2025 00:52:31, John Scott <jscott@posteo.net> a écrit : Yes, I use UTF-8 for some Debian releases, for me ISO-8859-1 is old and obsolete for a long time. 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 !! 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. 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. Trying this didn't succeed : gpg --import --import-options restore --display-charset UTF-8 cleComplete.gpg.asc 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.