Recover poorly backed up gpg secret keys

I have just restored my data from a borg backup repository after a computer failure.

My ~/.gnupg folder seems fine, private keys are there, and permissions look correct. Usually borg does a good job at this. When I cat the private keys files, there is no sign of data corruption.

However I cannot list or use the private keys. I can only interact with a public key that was imported by pacman during the installation process.

I came across a few posts with similar issues of private keys not recognised after being copied from one machine to another, and usually the problem gets solved following recommendations of repeating the transfer using gpg —export-key and then importing them with the opposite command.

Unfortunately I do not have that luxury since my old machine has crashed and is not recoverable. I was aware of importing and exporting keys, but I always assumed it was just a safe procedure to move keys around.

So I have two questions:

Do I have to review my backup scripts and use the export command for my gpg secret keys?

Can I recover my secret keys nonetheless?

======= Edit ======

I found a post on arch forum with a user having exactly the same problem I have, so I got more leads to follow.

What I tried so far:

gpg --version
> gpg (GnuPG) 2.4.5

ps aux | grep gpg-a
>  /usr/bin/gpg-agent --supervised

#About ownership: 
chown -R $USER:$USER .gnupg

# Checking UID/GID with show a result of `1000` both on filesystem # # and backup archive.
ls -vn .gnupg/private-keys-v1.d 

gpg --export-secret-keys
> gpg: WARNING: nothing exported

gpg -v --list-secret-keys
> gpg: enabled compatibility flags:
> gpg: using pgp trust model

# Most relevant results of:
strace -f -o /tmp/gpg.strace gpg --list-secret-keys
cat /tmp/gpg.strace
> 76220 access("/etc/", R_OK) = -1 ENOENT (No such file or directory)
> 76220 access("/home/$USER/.gnupg/secring.gpg", F_OK) = -1 ENOENT (No such file or directory)

# Listing public keys
gpg --list-keys
> Returns one public key imported by pacman during install

gpg -K
> Returns nothing

ls -ln .gnupg/
.rw-r-----   12 1000 13 Mar 10:45 common.conf
drwx------    - 1000  6 Sep  2023 crls.d
.rw------- 2.0k 1000 13 Sep  2023 gpg-agent.conf
.rw-------  703 1000  5 Mar 18:48 gpg.conf
drwx------    - 1000 30 Aug  2023 private-keys-v1.d
drwxr-x---    - 1000 14 Mar 19:27 public-keys.d
.rw-r--r--    0 1000 24 Aug  2023 pubring.gpg
.rw-r--r-- 7.7k 1000  5 Mar 12:13 pubring.kbx
.rw-r--r-- 7.0k 1000  7 Sep  2023 pubring.kbx~
.rw-------  600 1000  8 Mar 07:20 random_seed
.rw-r-----  676 1000 30 Aug  2023 sshcontrol
.rw------- 1.6k 1000  2 Sep  2023 trustdb.gpg
Asked By: lyndhurst


I am trying a garuda kde install at the moment, and it turns out it comes with some default gpg settings I have not yet completely figured out.

Anyway, it turns out some process is constantly recreating a basic .gnupg folder. It does not look like it is to blame on gpg agent since I was able to disable all gpg related systemd services (mainly gpg-agent.service and gpg-agent.socket) as both user and root and then killall gpg-agent.

What was happening is that I would never actually restore my own gpg folder from backups, but merging it with an automatically created and for some reasons it would not work.

Finally just to make sure I found the culprit, I could rm -rf the folder and restore it from backup using a script so that whatever process xas recreating it would not have the time to do so.

It has been working fine since.

Answered By: lyndhurst
Categories: Answers Tags: , ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.