☰

`gpg --recv-keys` 有效，但 `auto-key-retrieve` 无效

tag-icon • tag-icon gpg
`gpg --recv-keys` 有效，但 `auto-key-retrieve` 无效

我正在尝试验证该文件

https://clientupdates.dropboxstatic.com/dbx-releng/client/dropbox-lnx.x86_64-108.4.453.tar.gz

使用此处提供的签名：

https://clientupdates.dropboxstatic.com/dbx-releng/client/dropbox-lnx.x86_64-108.4.453.tar.gz.asc

我正在使用以下命令：

gpg --verify dropbox-lnx.x86_64-108.4.453.tar.gz.asc

这会产生以下输出：

gpg: assuming signed data in 'dropbox-lnx.x86_64-108.4.453.tar.gz'
gpg: Signature made Tue 20 Oct 2020 10:53:17 PM CEST
gpg:                using RSA key FC918B335044912E
gpg: Can't check signature: No public key

我的 GPG 配置~/.gnupg/gpg.conf如下所示：

keyserver keyserver.ubuntu.com
auto-key-retrieve

重点是auto-key-retrieve.此设置有效，如下所示：即使我没有相关的公钥，我之前也成功地验证了文件；在验证过程中按预期检索到了它。

gpg --search-keys FC918B335044912E还显示可以在我正在使用的密钥服务器上找到密钥。我也可以gpg --recv-keys，之后验证显然有效。

我的问题，这可能源于对 操作的误解gpg：为什么我可以手动获取有问题的密钥，但不能自动使用auto-key-retrieve，即使我知道它可以与其他密钥一起使用？

答案1

经过更深入的研究后，我想我现在至少可以自己部分地回答这个问题。当然仍然欢迎任何补充信息。 :)

原因可能是给定的签名不包含密钥的指纹，而只包含密钥 ID。例如，您可以使用 来查看这一点gpg --list-packets。对于有问题的签名，您会得到

:signature packet: algo 1, keyid FC918B335044912E
    version 4, created 1603227197, md5len 0, sigclass 0x00
    digest algo 8, begin of digest fd b9
    hashed subpkt 2 len 4 (sig created 2020-10-20)
    subpkt 16 len 8 (issuer key ID FC918B335044912E)
    data: [2046 bits]

对于另一个有效的签名，auto-key-retrieve它看起来像这样：

:signature packet: algo 1, keyid BCAA30EA9C0D5763
    version 4, created 1543944543, md5len 0, sigclass 0x00
    digest algo 10, begin of digest 84 51
    hashed subpkt 33 len 21 (issuer fpr v4 1A4E8B7277C42E53DBA9C7B9BCAA30EA9C0D5763)
    hashed subpkt 2 len 4 (sig created 2018-12-04)
    subpkt 16 len 8 (issuer key ID BCAA30EA9C0D5763)
    data: [2046 bits]

强调线条

    hashed subpkt 33 len 21 (issuer fpr v4 1A4E8B7277C42E53DBA9C7B9BCAA30EA9C0D5763)

man gpg在有关以下部分中明确指出auto-key-retrieve：

尝试查找密钥的方法的顺序是：

[...]

  1. 如果配置了任何密钥服务器并且发行者指纹是签名的一部分（自 GnuPG 2.1.16 起），尝试配置的密钥服务器。

（强调我的。）

--recv-keys另一方面也通过密钥 ID 进行查找。

旁注：Dropbox 密钥没有指纹很奇怪。删除密钥 ID 查找的部分原因，在这次提交从 2019-07-05 开始，是这样的即使这样指纹显然默认包含在签名中许久。 Dropbox 签名日期为 2020 年 10 月 20 日。一起行动吧，Dropbox！ xP

相关内容