大多数配置的第三方存储库都/etc/apt/sources.list.d
具有这样配置的签名密钥,例如:deb [signed-by=/etc/apt/keyrings/lutris.gpg] https://
。
然而,有些像 postgresql 的系统没有这个配置。那是问题吗?如果这可能是一个问题,但不一定是一个问题,如何检查是否存在?具体来说,postgresql repo 有一个存储库签名密钥但为什么不需要在那里指定呢?
此外,当在 Linux 下载页面运行数据库时运行这些步骤时
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
它已经说Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
运行时sudo apt-get update
输出包括:
宽:https://apt.postgresql.org/pub/repos/apt/dists/bookworm-pgdg/InRelease:密钥存储在旧版 trusted.gpg 密钥环 (/etc/apt/trusted.gpg) 中,有关详细信息,请参阅 apt-key(8) 中的弃用部分。 N:跳过配置文件“main/binary-i386/Packages”的获取作为存储库“https://apt.postgresql.org/pub/repos/apt bookworm-pgdg InRelease”不支持架构“i386”
- 后一个问题可以通过编辑文件
kwrite /etc/apt/sources.list.d/pgdg.list
来解决deb [arch=amd64] https:...
,但这不是必需的(设置应该按原样工作)。 - 这只留下了遗留的 trust.gpg 密钥环问题,可以使用长
for ...
命令来解决这里(这当然不是必需的!它应该默认或在提示用户后自动导入密钥,并且至少下载页面上的指南不应过时)。 - 完成所有这些后,剩下的问题是 pgdg.list 文件中未指定签名密钥是否不是问题。下载页面也需要更新。
答案1
有四点需要考虑。
关于
signed-by
(记录在man 5 sources.list
,其目的是确保给定存储库提供的包由特定密钥环中的密钥甚至特定密钥进行签名。如果没有此类条目的存储库遭到破坏并开始运送由 APT 密钥环中的另一个密钥签名的软件包,则不会触发错误。我认为从安全角度来看这不会产生重大差异。如果存储库签名密钥被泄露,则其打算签名的存储库很可能会被用来发送受损的软件包;在我看来,添加受损密钥在另一个存储库中签署软件包的功能并不会显着增加攻击面。主要的例外是添加到 APT 密钥环并被遗忘的密钥;但答案是停止使用 APT 密钥环。
对我来说,它的主要用途
signed-by
是作为文档:它记录了哪些键在哪里使用。这应该可以帮助管理员在删除关联的存储库时删除密钥。APT 存储库的主要弱点是它们共享相同的命名空间。因此,受感染的 APT 存储库可能会发布
libc6
比 Debian 版本更新的受感染软件包,并且使用该 APT 存储库的系统将升级到该软件包。对于系统管理员来说,最好的防御措施是限制第三方和第三方密钥的使用。改善每个人的情况需要在 Debian 方面做大量的工作(即使是一个“简单”的解决方案,例如记住软件包的来源,并在它更改存储库时发出警告,很快就会遇到可用性问题,因为 Debian 本身依赖至少在两个不同的存储库上,对于任何给定版本可能最多有四个存储库,并且目前没有办法阻止第三方存储库冒充 Debian(除了使用的密钥之外)。也可以看看如何保证 Debian 软件包的真实性?关于弃用
apt-key
,的“弃用”部分man 8 apt-key
准确解释了如何将wget
命令行转换为不依赖于apt-key
.关于该
i386
通知(这是完全良性的),是的,理想情况下应该更新 PostgreSQL 存储库指令(以及上述几点中描述的更改)。以上内容并非特定于 PostgreSQL;但特别是关于 PostgreSQL,为什么要使用第三方存储库? Debian 12 包含 PostgreSQL 15.6,它与上游 PostgreSQL 存储库提供的最新版本相同。 (是否需要使用旧版本?)