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

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

我认为我从未在其他任何地方看到过此建议。托管自己的存储库的大多数项目都说要下载其密钥文件并使用进行添加apt-key。

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

这些项目已经过时了。我之所以知道这一点，是因为我发布了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的密钥包，因为它们和存储库由发布者A的密钥签名，而不是由发布者B的密钥签名。

/etc/apt/trusted.gpg.d眼前的机制是一个较老的穷人的中途房子，从2005年左右开始，它的出现还有些瑕疵，那还不够好。它将密钥环设置在一个单独的文件中，以便可以将其打包并像其他任何文件一样由包管理器一步安装（或通过fetch/ curl/ 下载wget）。（程序包管理器可以防止发布者A的特殊“ this-is-my-repository-keyring”程序包安装在发布者B的上方，而通常情况下，它可以处理程序包之间的文件冲突。）但仍将其添加到密钥集中所有存储库在全球范围内都受到信任。现在存在的完整机制使用中的单独的，不受全局信任的密钥环文件/usr/share/keyrings/。

我的指示已经在那里。a正在采取行动将Debian自己的存储库移至该机制，以便它们也不再使用全局信任的密钥。您可能想对发现的“大多数项目”有所了解。毕竟，他们目前正在指导您将对计算机上APT的全局访问权交给他们。

进一步阅读

• 丹尼尔·卡恩·吉尔莫尔（2017-05-02）。 请将发行专用密钥单独运送到之外/etc/apt/trusted.gpg.d/。Debian错误＃861695。
• 丹尼尔·卡恩·吉尔莫（Daniel Kahn Gillmor）（2017-07-27）。 debian sources.list条目应该具有指向特定密钥的签署选项。Debian错误＃877012。
• “ Sources.list条目”。连接到第三方存储库的说明。Debian Wiki。2018。
• 为什么添加到sources.list没有安全风险？
• Debian 9，APT和“ GPG错误：... InRelease：以下签名无效：”

apt-key del接受keyid，这是密钥的无意义哈希。

如果您可以使用有意义的名称（例如文件名）来卸载密钥，则更为简单。

正如JdeBP所说，这与作为debian软件包的一部分安装的受信任密钥文件很好地配合使用。我认为手动安装密钥文件也会更好。

在当前处于“初始测试”中的新机制中，这可以进一步简化。您只需要删除/禁用一件事：存储库（位于sources.list / sources.list.d中）。这将自动停止允许为该存储库配置的密钥（除非另一个存储库也使用了该密钥）。

我不知道如何利用新的安全机制。我只是假设如果使用他们的包裹，我需要信任某人。软件包安装过程仍以root:-) 运行。