这Ubuntu apt-key 手册页包括以下有关的注释apt-key add
:
注意:不应使用此命令,而是应将密钥环直接放置在 /etc/apt/trusted.gpg.d/ 目录中,并使用描述性名称和“gpg”或“asc”作为文件扩展名。
我想我在其他地方从未见过这个建议。大多数托管自己存储库的项目都会要求下载其密钥文件并将其添加为apt-key
.
- 这个建议背后的动机是什么?
- 这是 Ubuntu 主义吗?还是适用于任何基于 APT 的发行版?
答案1
这些项目的说明已过时。我知道这一点是因为我发布了Debian 存储库当我发现 Debian 9 APT 中的更改时,我更新了我的说明。事实上,手册的这一部分现在已经过时了,因为它是错误的目录。
这实际上与目录无关.d
,更多的是为了防止 APT 中的跨站点漏洞。为了方便起见,旧系统使用单独的密钥环文件,但现在这是安全的必要条件;你的安全。
这就是漏洞。考虑两个存储库发布者 A 和 B。在 Debian 8 及之前的版本中,两个发布者的密钥都位于用户计算机上的单个全局密钥环中。如果发布者 A 能够以某种方式安排取代发布者 B 的存储库 WWW 站点,那么 A 就可以发布颠覆性软件包,用 A 自己的密钥签名,APT 会很乐意接受并安装。毕竟,A 的密钥对于所有存储库都是全局可信的。
缓解措施是让用户为各个发布者使用单独的密钥环Signed-By
,并在其存储库定义中引用具有单独设置的这些密钥环。具体来说,发布者 A 的密钥仅在存储库 A 中使用Signed-By
,发布者 B 的密钥仅在Signed-By
存储库 B 中使用。这样,如果发布者 A 取代了发布者 B 的存储库,APT 将不会接受其中的颠覆性软件包,因为它们和存储库由发布者 A 的密钥而不是发布者 B 的密钥签名。
目前的机制/etc/apt/trusted.gpg.d
是一个较老的穷人的有点缺陷的中途之家,从 2005 年左右开始,这还不够好。它将密钥环设置在一个单独的文件中,以便它可以像任何其他文件一样由包管理器打包并一步安装(或使用fetch
/ curl
/下载)。 wget
(包管理器负责阻止发布者 A 的特殊这是我的存储库密钥环但它仍然将其添加到所有存储库全局信任的密钥集中。现在存在的完整机制使用单独的、不是全球可信的密钥环文件/usr/share/keyrings/
。
我的指示已经在那里了。 ☺ 目前正在采取措施将 Debian 自己的存储库移至此机制,以便它们也不再使用全局可信密钥。您可能想谈谈您找到的“大多数项目”。毕竟,他们当前正在指示您将对计算机上 APT 的全局访问权限移交给他们。
进一步阅读
- 丹尼尔·卡恩·吉尔莫 (2017-05-02)。 请将特定于版本的密钥单独运送到外部
/etc/apt/trusted.gpg.d/
。 Debian 错误 #861695。 - 丹尼尔·卡恩·吉尔莫 (2017-07-27)。 debian
sources.list
条目应该有指向特定密钥的签名选项。 Debian 错误#877012。 - “来源.列表条目”。连接第三方存储库的说明。 Debian 维基。 2018.
- 为什么添加到sources.list不会带来安全风险?
- Debian 9、APT 和“GPG 错误:...InRelease:以下签名无效:”
答案2
apt-key del
接受keyid
,这是密钥的无意义散列。
如果您可以使用有意义的名称(例如文件名)来卸载密钥,那就更简单了。
正如 JdeBP 所说,这与作为 debian 软件包一部分安装的受信任密钥文件配合得很好。我认为手动安装密钥文件也会更好。
在目前处于“初步测试”的新机制中,这一点得到了进一步简化。您只需删除/禁用一件事:存储库(在sources.list/sources.list.d中)。这将自动停止允许为该存储库配置的密钥(除非它也被另一个存储库使用)。
我不知道如何利用新的安全机制。我只是假设如果我使用他们的软件包我需要信任某人。软件包安装过程仍在运行root
:-)。