Fish Shell 发布包完整性校验：从两条验证命令到发布流水线

Fish Shell 发布包完整性校验从两条验证命令到发布流水线【免费下载链接】fish-shellThe user-friendly command line shell.项目地址: https://gitcode.com/GitHub_Trending/fi/fish-shellFish Shell 是主打易用性的命令行 shell它的发布流程同样值得细看。本文讲清 fish 发布包的 SHA256 校验和 GPG 签名是怎么生成的如何在本地验证下载的包没被掉包以及校验和不匹配时按什么顺序排查最后把验证变成下载后的固定动作。下载的 fish 包怎么确认没被掉包shell 这种东西是要执行你机器上任何命令的所以装的东西是不是官方那一份比装什么都重要。你从镜像站或波动网络下载的 tar.xz可能在传输中损坏也可能被中间环节替换。官方发布页针对每个版本给出两层保护SHA256 校验和保证字节一致随附的.asc文件是 GPG 分离签名保证签名者确实是 fish 维护者。两道验证各管一件事SHA256 回答文件对不对任何一个字节不同哈希都会彻底改变。GPG 签名回答发布的人是谁镜像站就算替换了文件没有维护者的私钥也签不出能通过验证的签名。两者配合才构成完整的发布包完整性验证。本地只需要两条命令下载完成后对文件算哈希并与发布说明中的值比对再验一次签名openssl dgst -sha256 fish-4.8.1.tar.xz gpg --verify fish-4.8.1.tar.xz.asc fish-4.8.1.tar.xz没有 openssl 时用sha256sum也一样。两个结果都匹配这个包就可以放心解开了。校验和不匹配先查什么先怀疑传输再怀疑文件大多数不匹配其实是下载没下完或网络中断导致的。先看文件体积是否与发布页一致重新下载后再验一次。如果你是从第三方镜像拿的注意镜像自带的校验值没有权威性只认官方发布说明里的那份。再核对你手里比对的值确认三件事你比对的是同一个版本4.8.1和4.8.1-rc0的哈希完全不同哈希是从正确的发布说明段落复制的你验的文件确实是你想装的那个。换网络重新下载后仍然不匹配就停手别装换官方渠道再取。SHA256 和 GPG 签名是怎么生成的打包脚本顺手就算好了源码包的打包逻辑在 build_tools/make_tarball.sh用git archive加xz生成 tar.xz 后脚本末尾立即执行openssl dgst -sha256输出哈希打包和校验在同一个动作里完成。给 Rust 依赖做离线构建用的 build_tools/make_vendor_tarball.sh 同样带这一步保证 vendor 包也能被核验。发布流水线是一揽子动作完整的自动化流程定义在 .github/workflows/release.yml先校验 tag 是否真的是发布版本再构建源码包为 Linux 的 x86_64 和 aarch64 交叉编译静态链接二进制创建 draft release最后为 macOS 构建经过代码签名和公证的安装包。build_tools/release.sh 会用 GPG 对源码包生成fish-X.Y.Z.tar.xz.asc分离签名并上传build_tools/release-notes.sh 则在发布说明里明确写出签名文件的存放位置方便你核对。自己也能复现一遍如果你不放心可以拉一份仓库亲眼看看git clone https://gitcode.com/GitHub_Trending/fi/fish-shell翻一下 build_tools/ 下的脚本从打包到算哈希到签名整条链路都是明文可审计的。把验证变成下载后的固定动作以后每次拿到 fish 发布包动作固定成三拍比对 SHA256、验证 GPG 签名、确认版本一致。三拍全过再解压有一拍不过就停在原地。这一步多花半分钟换来的是对我装进去的东西到底是谁发的有完整答案。延伸阅读CHANGELOG.rst 查看版本发布记录doc_internal/ 内有 macOS 构建与公证细节。【免费下载链接】fish-shellThe user-friendly command line shell.项目地址: https://gitcode.com/GitHub_Trending/fi/fish-shell创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考