gpg2 import of gpg1 secret key fails (gpg 2.1.15, Ubuntu 17.10)

Question

When I try importing my nicely-exported gpg1 keys using gpg2, the public key import works fine:

gpg --import /path/to/publickey.gpg

gpg: directory '/home/me/.gnupg' created
gpg: new configuration file '/home/me/.gnupg/dirmngr.conf' created
gpg: new configuration file '/home/me/.gnupg/gpg.conf' created
gpg: keybox '/home/me/.gnupg/pubring.kbx' created
gpg: /home/me/.gnupg/trustdb.gpg: trustdb created
gpg: key ABCDEF1234567890: public key "Me <me@me.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

But importing the secret key fails (note: same result when using --allow-secret-key-import ):

gpg --import /path/to/secretkey.gpg

gpg: key ABCDEF1234567890: "Me <me@me.com>" not changed
gpg: key ABCDEF1234567890/ABCDEF1234567890: error sending to agent: No such file or directory
gpg: error building skey array: No such file or directory
gpg: Total number processed: 1
gpg:              unchanged: 1
gpg:       secret keys read: 1

I am on this (on Ubuntu Zesty 17.04):

gpg --version

gpg: WARNING: unsafe permissions on homedir '/home/me/.gnupg'
gpg (GnuPG) 2.1.15
libgcrypt 1.7.6-beta
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 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: /home/me/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cypher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

The exact same import steps work fine if I try with gpg 1.4.21 (on the same machine, can get it with sudo apt-get install gnupg1 ).

Answer 1

The differences between GnuPG 1.4 plus 2.0 and from 2.1 and above are explained in depth here . The first section of that page deals with the changes to the way secret keys are handled.

When you migrate to the modern branch of GPG from an existing instance of either 1.4 or 2.0 your secring.gpg file is imported into the new format and is not directly available as a keyring file. This will be done automatically the first time you invoke GPG 2.1 or 2.2. At the same time your public keyring ( pubring.gpg ) will be converted to the newer keybox format ( pubring.kbx ).

This conversion process is only performed once and GnuPG keeps track of this by writing a hidden file into your $GNUPGHOMEDIR (usually this is ~/.gnupg but can be confirmed by running gpgconf --list-dirs and the homedir should be the last line). The hidden file is named .gpg-v21-migrated and if, for whatever reason, you need to re-run the import process then simply deleting that file and restarting gpg-agent should do the job.

To reload gpg-agent properly, do this:

bash-4.4$ gpg-connect-agent
> RELOADAGENT
OK
> BYE
OK closing connection
bash-4.4$ 

To restart gpg-agent properly, do this:

bash-4.4$ gpg-connect-agent
> KILLAGENT
OK closing connection
bash-4.4$ 

The next GPG command will start it again.

As for the private-keys-v1.d/ directory; yes, it does contain secret key material, but it is in keygrip format and encrypted, it cannot be used directly the way the old secring.gpg file had been. You can, however, still export your secret keys to that format if you need to migrate systems or backup the keys or whatever else. That's essentially the same command as it was previously (including the export-options).

Answer 2

https://unix.stackexchange.com/questions/318385/no-such-file-or-directory-when-generating-a-gpg-key mentions that the "no such file or directory" can come from a missing directory ~/.gnupg/private-keys-v1.d

The gpg options --debug-level guru --debug-all --verbose may help diagose this a bit.

Answer 3

I had a similar problem. New versions of GPG seem to fail in the situation where they're trying to migrate your old secret keys to the new format, and you've restored your ~/.gnupg off of backup before installing a new GPG. For me, automatic migration failed, and my ~/.gnupg directory was left in a state where further attempts at migration also failed unless I cleaned up first.

The symptoms of the problem were the following:

• When I tried to decrypt using a secret key, I got the error message gpg: decryption failed: No secret key .

• When I did a gpg --list-public-keys , I got no output, even though I had the files ~/.gnupg/pubring.gpg and ~/.gnupg/secring.gpg .

The following process was what finally worked for me:

cd ~/.gnupg
gpgconf --kill gpg-agent
rm -Rf .gpg-v21-migrated private-keys-v1.d tofu.db
gpgconf --kill gpg-agent

After this I used gpg to decrypt something, this triggered migration, and the migration succeeded.