元数据签名校验核心是确认软件源真实可信，即先验证“货架”未被掉包；因其作为仓库目录清单记录所有包信息，一旦被篡改可导向恶意包，故优先于单包签名且为后续操作前提。
软件包元数据签名校验，核心是确认你正在使用的软件源（repository）本身真实可信——不是检查某个具体软件有没有被篡改，而是先确保“货架”没被掉包。
为什么元数据签名比单个包签名更关键
仓库元数据（如 repomd.xml 或 Release 文件）相当于整个软件源的“目录+清单”。它记录了所有可用包的名称、版本、大小、哈希值及下载地址。一旦这个文件被恶意替换，攻击者就能把用户引向伪造的、带后门的软件包，哪怕每个包自己有签名也无济于事。
所以包管理器默认优先校验元数据签名；只有它通过，后续的包列表加载、依赖解析、安装决策才继续进行。
如何确认你的源正在做元数据签名校验
不同发行版配置位置和判断方式略有差异，但逻辑一致：
- RHEL/CentOS/Fedora（dnf/yum）：检查 /etc/yum.repos.d/*.repo 中对应仓库段是否含 gpgcheck=1，且 gpgkey= 指向一个有效的本地公钥路径（如 file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora）
- Debian/Ubuntu（apt）：确认 /etc/apt/sources.list 或 /etc/apt/sources.list.d/*.list 中的源行未加 [trusted=yes]（这会绕过签名），真正起作用的是该源对应的公钥是否已导入到 /etc/apt/trusted.gpg.d/ 下的 keyring 文件中
- 执行 sudo apt update 或 sudo dnf makecache，观察输出里是否有类似 gpgv: Signature made ... using RSA key ID ... 的提示——有则说明签名正在被验证
常见失效原因与快速排查
元数据校验失败通常不会直接报错“签名无效”，而是表现为仓库无法更新、包列表为空或提示“no such file”等模糊错误。可按顺序检查：
- 系统时间严重偏差（早于密钥生效时间或晚于过期时间）——用 timedatectl status 查看并同步时间
- 对应公钥缺失或被误删——RPM 系统查 rpm -q gpg-pubkey，APT 系统查 ls /etc/apt/trusted.gpg.d/
- 签名文件（如 repomd.xml.asc）未随元数据同步下载——临时禁用 metalink 或换镜像源重试
- 仓库配置中 gpgcheck=0 被手动设为关闭——这是最常被忽略的安全降级
