VPN 的 APT 源：它授予什么，以及如何限制

下载一个 VPN 客户端是一次性决定；添加它的 APT 仓库则不是。后者告诉包管理器未来的软件可能来自哪里，这是一次长期的权限转移，而不是下载。当供应商妥善维护仓库时，这可以是正确的安排。但它仍然值得一个有意识的决定，而大多数安装指南都跳过了这一点。

签名认证的是归档，而不是其中的代码

APT 校验已签名的仓库元数据，然后信任该元数据中的校验和，用它来验证所获取的软件包。这只能证明归档与密钥持有者发布的内容一致，对里面的代码一无所知。一个签名正确的软件包仍可能带有不安全的维护者脚本，而这些脚本会在安装过程中以 root 身份运行。apt-secure 手册正是在归档认证与软件审查之间划出这条界线。

所以有用的问题不是签名是否有效——损坏的签名本来就会中止安装。问题在于，从现在起你选择信任谁的签名。被窃取的签名密钥比被窃取的软件包更糟，因为攻击者能在第一次坏发布之后很久仍持续产出有效元数据。唯一的补救是轮换密钥，而这取决于供应商是否通过你能独立验证的渠道发布新密钥。

这就是为什么密钥身份值得和仓库 URL 一样重视。从旧论坛回答里的地址拿到的密钥，对发布者没有任何证明；HTTPS 只保护到接电话那一步的传输。传输安全与发布者身份是两个问题，证书只能解决前者。

把密钥限定在源上，而不是系统上

现代 APT 接受针对特定源的 Signed-By 引用。由运维管理的密钥可以放在 /etc/apt/keyrings/ 下，源条目会指明哪个密钥可以认证该归档。这比把同一个密钥丢进全局信任集合要窄得多，因为在那里它可能为你从未想允许的源作保。请遵循已安装的 APT 版本和供应商当前的说明，而不是把不同代指南的片段混在一起。

curl -fsSL https://repo.example.com/vpn-key.gpg -o /etc/apt/keyrings/vpn.gpg
echo "deb [signed-by=/etc/apt/keyrings/vpn.gpg] https://repo.example.com/debian stable main" > /etc/apt/sources.list.d/vpn.list

绝不要通过关闭校验或把未知归档标记为可信来修复签名失败。那是用一个看不见的错误替换一个看得见的错误，而看不见的错误会一直存在，直到有人审计源列表。如果密钥不匹配，正确的做法是找到正确的密钥，而不是去掉检查。

从项目或受管管理员那里获取仓库详情和密钥身份。从博客文章里复制的密钥是对作者身份的声称，而不是证据。当供应商公布轮换渠道时，把它和密钥一起记录下来，因为正是这个渠道让下一次轮换成为可能。

源固定不是软件包白名单

把密钥限定在一个源上，限制的是它能认证哪个归档，而不是那个归档可以发布哪些软件包。仓库可能提供远超你所需 VPN 客户端的内容，而 APT 的候选选择和优先级决定哪个合格版本胜出。确认之前先审阅拟议的事务，包括依赖列表，因为依赖也来自同一个归档。密钥范围无法表达“仅此软件包”。

如果你需要更强的控制，就把它表述为针对软件包名称或版本的策略，并把该策略纳入配置管理。读一次事务只要一分钟；半年后发现一个意外的软件包需要一次审查。

意外出现的软件包是停下来的时刻，而不是继续的理由；该问归档所有者的是它们为什么被需要。围绕一个客户端发布十几个软件包，对交付桌面套件的供应商来说是正常的。这也比安装指南暗示的表面积更大，而这正是值得记录的部分。两种结果都不是不信任签名的理由；两者都是写下你接受了什么的理由。

记录这项权限以及如何移除它

写下归档所有者、受支持的操作系统版本、密钥轮换渠道和移除流程。这四项事实正是继任者在客户端退役或供应商轮换密钥时所需要的。没有它们，下一个人继承的只是一行源配置和一个密钥文件，没有任何来龙去脉。

移除是最容易被跳过的一步，所以在安装时就写下来。把源条目和它的专用密钥一起删掉，并在删除文件之前检查该密钥是否在别处被引用。未经这项检查就删除共享密钥，会把一次清理变成一次无关的故障，这是例行变更最糟糕的结果。然后确认条目消失后普通更新仍能正常解析。

移除仓库之后还剩一件事：任何已从中安装的软件包会继续运行，直到有别的东西取代它。诚实的问题是：你添加了哪项权限，以及它的角色被表述得有多窄。