在计算机发生故障后，我刚刚从 borg 备份存储库恢复了我的数据。
我的~/.gnupg文件夹看起来不错，私钥在那里，权限看起来正确。通常博格在这方面做得很好。当我cat查看私钥文件时，没有数据损坏的迹象。
但是我无法列出或使用私钥。我只能与pacman在安装过程中导入的公钥进行交互。
我遇到过一些类似的帖子，这些问题涉及从一台机器复制到另一台机器后无法识别私钥的问题，通常按照重复使用传输的建议gpg —export-key，然后使用相反的命令导入它们，问题就会得到解决。
不幸的是，我没有这样的奢侈，因为我的旧机器已经崩溃并且无法恢复。我知道导入和导出密钥，但我始终认为这只是移动密钥的安全过程。
所以我有两个问题：
我是否必须检查我的备份脚本并对我的 gpg 密钥使用导出命令？
我还能恢复我的密钥吗？
=======编辑======
我发现了一个邮政在 arch 论坛上，一位用户遇到了与我完全相同的问题，所以我得到了更多线索可以跟踪。
到目前为止我尝试过的：
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/ld.so.preload", 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
答案1
我现在正在尝试安装 garuda kde，结果发现它带有一些我尚未完全弄清楚的默认 gpg 设置。
不管怎样，事实证明某个进程正在不断地重新创建一个基本.gnupg文件夹。它看起来并不像是 gpg 代理的责任，因为我能够以用户和 root 身份禁用所有与 gpg 相关的 systemd 服务（主要是gpg-agent.service和gpg-agent.socket），然后是killall gpg-agent。
发生的情况是，我永远不会真正从备份中恢复我自己的 gpg 文件夹，而是将其与自动创建的文件夹合并，并且由于某些原因它无法工作。
最后，为了确保找到罪魁祸首，我可以rm -rf使用脚本从备份中恢复该文件夹，这样无论重新创建它的进程都没有时间这样做。
从那以后它一直运行良好。