我们有一个私有的 Debian 存储库,是由一位早期的系统管理员在几年前建立的。软件包由较旧的密钥 7610DDDE(我必须撤销该密钥)签名,如下图所示,存储库服务器上的 root 用户。
# gpg --list-keys
/root/.gnupg/pubring.gpg
------------------------
pub 1024D/2D230C5F 2006-01-03 [expired: 2007-02-07]
uid Debian Archive Automatic Signing Key (2006) <[email protected]>
pub 1024D/7610DDDE 2006-03-03 [revoked: 2016-03-31]
uid Archive Maintainer <[email protected]>
pub 4096R/DD219672 2016-04-18
uid Archive Maintainer <[email protected]>
以下所有命令均以 root 用户身份执行。我修改了repository/conf/distributions 文件以使用我明确创建的新子密钥进行签名:
Architectures: i386 amd64 source
Codename: unstable
Components: main
...
SignWith: DD219672
但是当我使用 dput 更新包时,我得到了
Could not find any key matching 'DD219672'!
ERROR: Could not finish exporting 'unstable'!
This means that from outside your repository will still look like before (and
should still work if this old state worked), but the changes intended with this
call will not be visible until you call export directly (via reprepro export)
当我直接运行 reprepro export 时,我得到:
# reprepro -V export unstable
Exporting unstable...
generating main/Contents-i386...
generating main/Contents-amd64...
Could not find any key matching 'DD219672'!
ERROR: Could not finish exporting 'unstable'!
我在 Google 上搜索并发现了一些旧线程,这些线程表明 reprepro 可能在查找正确的 gnupg 目录时存在问题...所以我尝试了这个,得到了与上面相同的结果:
# GNUPGHOME=/root/.gnupg reprepro -V export unstable
一个线程建议通过签署一个虚拟文件来测试密钥,这似乎工作正常...至少它没有报告错误,并且完成后我得到了一个 576 字节的 bla.gpg 文件。
# touch bla
# gpg -u DD219672 --sign bla
reprepro 手册页还建议“如果签名有问题,您可以尝试gpg --list-secret-keys 值看看 gpg 如何解释该值。如果该命令未列出任何键或多个键,请尝试查找其他值(如 keyid),gpg 可以更轻松地将其与唯一键关联起来。所以我也检查了这一点,并得到了:
# gpg --list-secret-keys DD219672
sec 4096R/DD219672 2016-04-18
uid Archive Maintainer <[email protected]>
最后,我终于联系上了最初设置我们的复制品的系统管理员,他建议我尝试使用没有密码的密钥。所以我生成了一个新的签名密钥 DD219672,发布了它,再次执行了上述步骤,但结果相同。
今天,在阅读和研究了更多手册页并注意到运行 reprepro 时 pgp-agent 会自动启动后,我决定追踪它一段时间。
我添加了一个 gpg-agent.conf
debug-level 7
log-file /root/gpg.agent.log
debug-all
我可以在日志中看到 gpg-agent 没有找到密钥
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK Pleased to meet you, process 18903
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- RESET
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION ttyname=/dev/pts/0
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION ttytype=xterm-256color
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- GETINFO version
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> D 2.1.11
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION allow-pinentry-notify
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION agent-awareness=2.1.0
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- AGENT_ID
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> ERR 67109139 Unknown IPC command <GPG Agent>
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- HAVEKEY C2C5C59E5E90830F314ABB66997CCFAACC5DEA2F 416E8A33354912FF4843D52AAAD43FBF206252D9 8CE77065EA6F3818A4975072C8341F32CB7B0EF0
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> ERR 67108881 No secret key <GPG Agent>
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- [eof]
到目前为止,我还无法弄清楚 gpg-agent 在哪里找到它在 HAVKEY 中列出的密钥,以及如何指向正确的方向以找到新密钥 DD219672 来签署我们更新的软件包。
答案1
我也遇到了同样的问题,经过多次尝试后终于找到了问题的根源。
该reprepro
工具使用基于gnupg2
。最新版本的 gpgme 改变了密钥环的处理方式:https://www.gnupg.org/faq/whats-new-in-2.1.html
gpg 过去将公钥对保存在两个文件中:
pubring.gpg
和secring.gpg
... GnuPG 2.1 改变了这一点 ... 为了简化向无保密方法的迁移,gpg 会检测是否存在,secring.gpg
并将密钥即时转换为 gpg-agent 的密钥存储(这是private-keys-v1.d
GnuPG 主目录 (~/.gnupg
) 下的目录)。此操作仅执行一次,secring.gpg
之后 gpg 不再触及现有的。这允许旧版 GnuPG 与 GnuPG 2.1 共存。但是,使用新 gpg 对私钥所做的任何更改都不会在使用 2.1 之前的 GnuPG 版本时显示,反之亦然。
因此,如果您使用 gpg 创建一个新密钥,gpg2 将看不到它,反之亦然。
对我有用的快速修复:
gpg --export-secret-keys | gpg2 --import -
当然,如果你需要换一种方式:
gpg2 --export-secret-keys | gpg --import -
根据您的设置,您可能还需要添加--export-secret-subkeys
完成上述操作后,reprepro
我的新密钥就可以正常工作了。
答案2
对我来说,问题是我以用户身份生成密钥和以 root 身份运行 reprepro。
发生的事情是,我“不带”生成的密钥sudo
被添加到我的本地pubring.gpg
。当我运行时,sudo reprepro ...
我以 root 身份运行它,因此它尝试在 root 中查找密钥pubring.gpg
,但显然找不到。
解决方案是以gpg
root 身份运行所有命令(例如sudo -i
然后gpg --gen-key
)。确保运行时sudo gpg --list-keys
可以看到所需的键和行/root/.gnupg/pubring.gpg
。
希望有帮助!