Linux 内核源码包怎么验签：tar.xz、tar.sign 与维护者指纹的对应关系

从 kernel.org 下载 Linux 内核源码后，只核对文件名并不够。官方同时提供 tar.xz 和 tar.sign，最容易踩的坑是直接拿压缩包验签：这份分离签名实际对应解压后的 .tar 文件。验签对象选错，即使两个下载都没有损坏，也得不到正确结果。

先把三个文件和信任锚点对上

以 kernel.org 当前稳定分支的源码包为例，下载页给出压缩源码与分离签名。linux-7.2.2.tar.xz 负责传输，解压后得到 linux-7.2.2.tar；linux-7.2.2.tar.sign 则用于验证这个 tar。这样做的好处是，同一份签名可以对应不同压缩格式解开后的同一归档内容。

信任链还包括维护者公钥和指纹。公钥可以完成密码学核对，指纹用来确认拿到的是哪位发布维护者的密钥。kernel.org 的签名说明页列出了常见发布者指纹；团队环境应固定从官方页面核对，不要从搜索摘要或陌生镜像复制一串看似相同的字符。

最小可复用的验签命令

以下命令沿用 kernel.org 官方说明的顺序。版本号要替换成实际下载版本，源码包与签名文件必须来自同一个发布条目：

curl -OL https://cdn.kernel.org/pub/linux/kernel/v7.x/linux-7.2.2.tar.xz
curl -OL https://cdn.kernel.org/pub/linux/kernel/v7.x/linux-7.2.2.tar.sign

unxz linux-7.2.2.tar.xz
gpg2 --locate-keys torvalds@kernel.org gregkh@kernel.org
gpg2 --verify linux-7.2.2.tar.sign linux-7.2.2.tar

--locate-keys 解决“本机没有发布者公钥”的问题，但下载到公钥之后仍要比对完整指纹。这里别急着把信任警告当成失败：它通常表示签名在密码学上有效，但本地尚未建立对该公钥的信任关系。这和内容被篡改是两件事。

Good signature 之后还要判断什么

“Good signature” 只能说明当前公钥与当前文件匹配，不能单独证明公钥身份可靠。继续查看输出里的主密钥指纹，与 kernel.org 官方维护者指纹逐组比对。团队自动化可以固定允许的完整指纹，但首次建立清单时仍应由两人复核来源。

“BAD signature” 则是硬停止条件。常见原因包括把 tar.sign 错配给 tar.xz、版本号不一致、下载被截断，或文件在传输后发生变化。不要通过忽略错误继续编译，也不要重新下载签名去“配合”一个来源不明的源码包。

常见问题

能不能直接验证 linux-7.2.2.tar.xz？

不能直接拿官方 tar.sign 对压缩包核对。先用 unxz 得到 tar，或者使用官方给出的管道写法把解压内容交给 gpg2。

只比对下载页的哈希值够吗？

哈希适合发现传输损坏，但如果哈希和文件来自同一不可信位置，无法建立发布者身份。内核源码更适合同时核对分离签名和维护者指纹。

正式构建前，把“源码包、分离签名、公钥、完整指纹”作为一个整体保存到构建记录中。下次升级只替换版本对应的文件，不改变验签顺序，排查起来会清楚很多。