为什么 apt-key 手册页建议不要使用其 add 命令？

Question

apt-key的Ubuntu 手册页包含以下关于以下内容的注释apt-key add：

注意：不应使用此命令，而是应将密钥环直接放置在 /etc/apt/trusted.gpg.d/ 目录中，并使用描述性名称和“gpg”或“asc”作为文件扩展名。

我想我从来没有在其他地方看到过这个建议。大多数托管自己存储库的项目都说要下载他们的密钥文件并将其添加到apt-key.

1. 这个建议背后的动机是什么？
2. 这是 Ubuntu 主义，还是适用于任何基于 APT 的发行版？

Answer 1

这些项目的说明已经过时。我知道这一点是因为我发布了一个 Debian 存储库，并且当我发现 Debian 9 APT 中的更改时更新了我的说明。事实上，手册的这一部分现在已经过时了，因为它是错误的目录。

这实际上与.d目录无关，而是与防止 APT 中的跨站点漏洞有关。旧系统为方便起见使用单独的密钥环文件，但现在这是安全的必要条件；你的安全。

这就是漏洞。考虑两个存储库发布者，A 和 B。在 Debian 8 及之前的世界中，两个发布者的密钥都放在用户机器上的单个全局密钥环中。如果发布者 A 能够以某种方式安排取代发布者 B 的存储库 WWW 站点，那么 A 可以发布使用 A 自己的密钥签名的颠覆性软件包，APT 很乐意接受并安装这些软件包。毕竟，A 的密钥对于所有存储库来说都是全局可信的。

缓解措施是让用户为各个发布者使用单独的密钥环，并Signed-By在其存储库定义中使用单独的设置来引用这些密钥环。具体来说，发布者 A 的密钥仅在Signed-By存储库 A 中使用，发布者 B 的密钥仅在Signed-By存储库 B 中使用。 这样，如果发布者 A 取代发布者 B 的存储库，APT 将不会接受来自它的破坏性包，因为它们和存储库由发布者 A 的密钥而不是发布者 B 的密钥签名。

/etc/apt/trusted.gpg.d手头的机制是一个年长的穷人在这方面有点缺陷，从 2005 年左右开始，这还不够好。它设置在一个单独的文件中的密钥环，以便它可以被包装起来并刚刚安装在一个步骤中由包管理器（或下载fetch/ curl/ wget）的任何其他文件。（包管理器处理阻止发布者 A 的特殊this-is-my-repository-keyring包安装在发布者 B 上，以正常方式处理包之间的文件冲突。）但它仍然将它添加到密钥集中所有存储库都受到全球信任。现在存在完整的机制使用独立的，不是全球受信任的，在密钥环文件/usr/share/keyrings/。

我的指示已经在那里了。☺ 目前正在将 Debian 自己的存储库迁移到这种机制，以便它们不再使用全局信任的密钥。您可能想说一下您找到的那些“大多数项目”。毕竟，他们目前正在指示您将机器上对 APT 的全局访问权交给他们。

进一步阅读

• 丹尼尔·卡恩·吉尔莫 (2017-05-02)。 请在/etc/apt/trusted.gpg.d/. Debian 错误 #861695。
• 丹尼尔·卡恩·吉尔莫 (2017-07-27)。 debiansources.list条目应该具有指向特定键的签名选项。Debian 错误 #877012。
• “Sources.list 条目”。连接到第三方存储库的说明。Debian 维基。2018 年。
• 为什么添加到sources.list 没有安全风险？
• Debian 9、APT 和“GPG 错误：... InRelease：以下签名无效：”