APT更新报Conflicting values set for option Signed-By，软件源冲突解决方法

在Debian或Ubuntu服务器执行 apt update 时，如果出现 Conflicting values set for option Signed-By regarding source，APT通常还会列出两个不同的密钥环路径。这个错误发生在下载软件包索引之前，说明同一仓库被多次定义，而且这些定义对验证密钥的要求不一致。

真正需要修复的是重复或冲突的软件源配置，不是关闭仓库签名校验。 Signed-By用于限定某个仓库可以由哪些密钥签名，随意删除安全选项或把源设为trusted会扩大信任范围。

先完整记录报错与系统版本

先重新运行更新并保存原始输出，不要只截取最后一行：

sudo apt update
apt --version
. /etc/os-release && printf '%s %s\n' "$ID" "$VERSION_ID"

错误中会显示仓库URI、发行版代号以及冲突的Signed-By值，例如一个条目指向 /usr/share/keyrings/vendor.gpg，另一个指向 /etc/apt/keyrings/vendor.gpg。这两个文件即使包含相同公钥，对APT而言也仍是不同配置值。

先记下完整URI与suite，再查定义位置。 不要因为错误提到了密钥就立刻重新下载密钥，重复源没有消除时，新密钥通常不能解决配置冲突。

找出同一仓库的所有定义

APT会同时读取 /etc/apt/sources.list 以及 /etc/apt/sources.list.d/ 下扩展名为 .list 和 .sources 的文件。可先列出全部有效条目：

grep -RInE '^[[:space:]]*(deb |Types:|URIs:|Suites:|Signed-By:)' \
  /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null

还可以针对报错里的域名缩小范围：

grep -RInF 'packages.example.com' \
  /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null

常见情况是旧的 .list 文件尚未删除，新安装脚本又创建了deb822格式的 .sources 文件；也可能同一仓库分别以HTTP和HTTPS、带尾斜线和不带尾斜线的形式存在。比较时必须同时核对URI、Suites、Components、Architectures和Signed-By，不能只看文件名。

备份后统一重复条目

修改前先备份相关文件，而不是备份整个APT缓存：

sudo cp -a /etc/apt/sources.list.d/vendor.list \
  /etc/apt/sources.list.d/vendor.list.bak
sudo cp -a /etc/apt/sources.list.d/vendor.sources \
  /etc/apt/sources.list.d/vendor.sources.bak

如果两个条目确实描述同一个仓库和发行版，保留一份即可。新系统可以保留可读性更好的deb822条目：

Types: deb
URIs: https://packages.example.com/debian
Suites: stable
Components: main
Signed-By: /etc/apt/keyrings/vendor.gpg

旧的一行式配置则类似：

deb [signed-by=/etc/apt/keyrings/vendor.gpg] https://packages.example.com/debian stable main

示例域名和代号不能直接照搬。必须以供应商为当前系统版本提供的官方仓库配置为准，并确保同一URI与suite使用一致的安全选项。

检查密钥环路径与读取权限

统一条目后确认密钥环真实存在，并且APT使用的 _apt 用户能够读取。系统管理员自行管理的密钥环推荐放在 /etc/apt/keyrings，由软件包提供的密钥环通常位于 /usr/share/keyrings。

sudo stat /etc/apt/keyrings/vendor.gpg
sudo -u _apt test -r /etc/apt/keyrings/vendor.gpg
printf 'readable=%s\n' "$?"

如果文件不存在，应从供应商官方渠道重新获取并按其说明转换格式；不要从搜索结果、论坛附件或不明镜像复制密钥。也不要使用 chmod 777，普通的全局只读权限已经足够。

需要先验证第三方仓库变更，可在 萤光云 建立临时测试机；要对比不同地区的软件源可用性，也可使用 LightNode 创建隔离节点。测试机不要复制生产仓库凭据。

清理索引并验证更新结果

配置语义修正后先执行普通更新：

sudo apt update

只有在不再报Signed-By冲突、但本地索引本身仍损坏时，才清理列表并重新下载：

sudo rm -rf /var/lib/apt/lists/*
sudo apt update

删除 /var/lib/apt/lists 不会删除已安装软件，但会让APT重新下载索引。不要删除 @@HTMLTOKEN1@@，也不要用 @@HTMLTOKEN2@@ 掩盖签名问题。

验收时应确认 apt update 正常结束、目标仓库只出现一次、没有NO_PUBKEY或unsigned警告，并用 apt-cache policy 查看候选包确实来自预期仓库。

FAQ

能直接删掉所有Signed-By吗？

不建议。这样可能让仓库接受系统全局信任库中的其他密钥，扩大信任边界。应统一为供应商指定的专用密钥环。

同一个密钥复制到两个路径为什么仍会冲突？

因为APT比较的是源条目的配置值，不会先验证两个文件内容是否相同。同一仓库应引用一致路径。

@@HTMLTOKEN0@@和@@HTMLTOKEN1@@哪种格式更合适？

APT两种都支持；Debian文档说明deb822格式从APT 1.1起受支持，而一行式格式已被标记为逐步弃用。迁移时重点是不要保留重复定义。

温馨提示

软件源签名配置属于供应链安全边界。处理冲突时先备份、再合并重复源、最后验证密钥路径；任何关闭认证或扩大trusted范围的做法都不应作为长期方案。