科技 · 实用指南
APT 报 NO_PUBKEY？先核验仓库，再用 Signed-By 修复密钥配置
先把错误对应到实际启用的源，核验发布者与完整指纹，再检查密钥格式、_apt 权限和 Signed-By；最后确认同一仓库恢复签名验证。
APT 的 NO_PUBKEY 表示：仓库元数据的签名所用密钥，APT 无法在该源的配置下使用。这不证明论坛或密钥服务器上的某把密钥就是正确密钥，也不是关闭签名检查的理由。
安全修复应限定到具体仓库：保留报错，定位源条目，通过发布者官方渠道核验仓库身份与完整指纹，使用格式正确的专用密钥环，以 Signed-By 绑定，再不带任何信任绕过选项重跑更新。
1. 修改信任之前，保留完整错误
再次正常运行更新并保存完整输出，记录 NO_PUBKEY 标识、仓库 URL、suite 或发行代号，以及错误指向 InRelease 还是 Release.gpg。暂时不要添加密钥。多个第三方源可能同时产生无关警告；应根据主机名和 suite 定位，而不是消息先后顺序。
检查 /etc/apt/sources.list，以及 /etc/apt/sources.list.d 中 APT 识别的 .list 和 .sources 文件。读完整匹配行或 deb822 段，包括 URIs、Suites、Signed-By、Enabled。被注释的 .list 行与 Enabled: no 段已停用，其他扩展名的备份不是启用条目。匹配报错 URL 与 suite，并记录所有启用的重复项；递归搜索只能辅助定位，不能证明 APT 加载了某条配置。
2. 区分发行版官方仓库与第三方仓库
默认安装的 Debian、Ubuntu 已通过发行版维护的密钥环软件包提供官方仓库密钥。官方仓库缺少密钥，可能与密钥环过旧、发行版本不再受支持、源填写错误或安装损坏有关。先确认系统版本与官方仓库 URL，再考虑手动下载。
第三方仓库应使用厂商官方设置页面或密钥发布文档。若无法独立确认仓库 URL、发布者身份和公布的完整指纹之间的关系，就停用该源。随意导入一把密钥可能改变报错，却不能证明谁控制仓库。
3. 安装之前，核验完整指纹
仅从已确认的发布者渠道下载候选公钥到临时文件。用 `gpg --show-keys --with-fingerprint --with-subkey-fingerprint /path/to/candidate-key` 查看，不把它加入受信任密钥环。将完整主密钥指纹逐字符与仓库所有者另一官方页面公布的指纹比较。
末尾八位或十六位与 NO_PUBKEY 标识一致，不足以批准密钥。密钥服务器结果、论坛命令、跳转地址和看起来熟悉的用户标识也不构成身份核验。若官方说明正在轮换密钥，先记录旧、新指纹及适用的操作说明。
4. 使用格式正确的专用密钥环
需要时创建 /etc/apt/keyrings，由 root 所有，并允许遍历目录。ASCII 装甲公钥使用 .asc，导出的二进制 OpenPGP 密钥环使用 .gpg。Debian 文档明确区分现代 GnuPG keybox 与 APT 密钥环；不要把私人 GnuPG 主目录或 keybox 复制进来。
核验指纹后，只安装公钥材料，使用仓库专用文件名、root 所有者及 0644 权限。用 file、gpg --show-keys --with-fingerprint、stat，以及 `sudo -u _apt test -r /etc/apt/keyrings/vendor-archive-keyring.asc` 检查。若最后一项失败，用 namei -l 检查所有上级目录；文件可读但目录不可遍历，_apt 仍无法访问。
5. 用 Signed-By 限定仓库密钥
对 deb822 .sources，在已核验 URI 和 suite 的段中加入 `Signed-By: /etc/apt/keyrings/vendor-archive-keyring.asc`。旧式 .list 则把 `signed-by=/etc/apt/keyrings/vendor-archive-keyring.asc` 放在 deb 后的选项方括号内。使用实际安装的 .asc 或 .gpg 文件名，扩展名应对应密钥表示形式。
Signed-By 限定哪些密钥能认证该仓库，比将全部第三方密钥放入全局信任更有边界，但不保证发布的软件包无害。逐个仓库迁移，备份原条目，限定后的源通过验证前不要移除旧全局密钥。若引用文件含多把公钥且未指定指纹，文件中的密钥都会被允许；检查完整文件，遵循发布者明确的密钥选择说明，不信任来源不明的密钥集合。
6. 验证仓库，不只看退出码
不带不安全选项运行 `sudo apt-get update`。目标仓库应能获取并认证元数据，不再出现 NO_PUBKEY、签名无效或密钥环不可读消息。核对成功输出的主机名和 suite 与起初定位的一致；其他镜像成功不证明原失败条目已经修复。
对预期来自该仓库的软件包运行 `apt-cache policy PACKAGE_NAME`，确认候选版本与来源符合预期。记录源文件路径、仓库 URI 与 suite、已核验的完整指纹、安装的密钥环路径和 SHA-256、权限、更新结果与软件包来源检查。这样的记录便于以后轮换密钥及审查异常。
7. 失败时排查，保持认证开启
指纹不同、官方页面不可用、密钥过期或撤销却没有官方替代说明，或仓库身份突然改变，都应停止使用并联系发布者。指纹一致仍报 NO_PUBKEY，则复查 Signed-By 路径、密钥格式、_apt 可读性、重复源，以及 Release 元数据是否确实用该密钥签名。
trusted=yes、allow-insecure=yes、Acquire::AllowInsecureRepositories 或未经认证的安装，会压低触发错误的认证控制。Debian 把这些方式描述为降低安全性的例外，不是修复密钥的步骤。发布者、密钥与已签名元数据形成可核验链条之前，保持该仓库停用。
