桌面应用的下载信任：校验和、签名与构建来源各自证明什么

假设同一个桌面应用在发行页和一个镜像站上都提供下载。文件名称相同，版本号也相同，用户却仍然需要回答：它们是不是同一份文件？由谁发布？是否来自预期的代码和构建过程？适不适合在自己的设备上运行？

这些问题需要不同的证据。把所有验证方式统称为“安全认证”，容易让用户期待它们实际无法保证的事情，也会让开发者忽略发行流程中的空白。

校验和回答文件是否一致

下载后计算哈希，并与预期值比较，可以检查文件内容是否一致。但这里有一个重要前提：预期值本身来自可信渠道。如果文件与校验值都来自同一个未经确认的页面，两者一致仍不足以证明发布者身份。

反过来，哈希不同意味着文件存在差异，却不能仅凭这一点断定恶意。不同构建、重新打包或错误下载都可能造成变化。正确做法是暂停把它当作已验证版本，重新确认文件来源、目标平台和对应的校验记录。

对发行方而言，清晰的文件命名、版本信息和校验清单，应当一起维护。不要让用户从旧文章复制一串哈希，再拿它比较另一个平台或另一次构建的安装包。

签名需要验证“预期是谁”

数字签名把签名者与被签数据关联起来，但验证程序还需要判断这个身份是否符合预期。Sigstore 的验证文档要求核对签名以及相关身份、签发者等条件，体现的就是这种区分。Sigstore 验证文档

因此，用户看到“签名有效”时，还应确认它对应哪个发布者或工作流；开发者则应明确允许哪些身份签署正式发行物。任何能通过某种数学验证的签名，都不应自动获得产品正式版本的地位。

发行方更换证书或签名方式时，也需要提供可核对的说明。让用户临时信任一个来历不明的证书，并不是一个完整的更新流程。

构建来源把安装包连接到生产过程

GitHub 的 artifact attestation 可以记录构建来源，帮助验证产物与仓库、工作流等信息的关联。它为核对“这份文件怎样产生”提供了证据，但验证时仍需检查实际产物及预期身份。GitHub 构建证明文档

SLSA 的构建等级进一步区分来源记录的存在、托管平台生成的签名来源记录，以及更严格的构建平台防护要求。引用等级时，应说明适用范围与依据，不能把等级数字当作覆盖所有软件风险的评分。SLSA 构建等级

这些证据可以相互补充。开发者应让用户知道已经提供了哪些证据，以及哪些检查还需要独立完成。

可复现构建需要明确输入与环境

Reproducible Builds 项目把可复现构建定义为：给定相同源代码、构建环境和构建说明，能够得到逐字节一致的指定产物。它比“在我的电脑上能编译”提出了更明确的验证目标。可复现构建定义

我们建议发行方保留工具链、依赖锁定信息、构建参数与产物对应关系。若尚未达到可复现，也应准确记录目前能够重建到哪一步，而不是省略差异后宣布通过。

公开仓库的范围也要讲清楚。仓库可能包含核心源码，也可能主要包含构建工具、配置和上游生成的应用包。用户需要知道自己实际能检查和重新构建哪些部分，才能合理评价来源证据。

用户可以采用的下载检查顺序

1. 从项目的正式入口确认发行仓库，避免仅依赖搜索广告或转发链接。
2. 阅读版本说明，确认操作系统、处理器架构和发行通道。
3. 核对文件与对应校验值；有签名或来源证明时，再验证预期身份及适用范围。
4. 检查维护状态和已知限制，避免把“最新标签”直接理解为适合生产使用。
5. 遇到信息不一致时，保留版本与文件名，通过项目支持渠道核实。

这套流程不要求每位用户都成为构建工程师。产品可以把复杂证据整理成清楚的发行页面：文件从哪里来、适合谁、怎样检查、出现异常去哪里询问。

对开发者来说，长期维护这条信息链比一次性贴出“已验证”的标签更有价值。旧版本撤回、签名更换和更新失败时，用户仍应找得到对应说明。

AlphaBiz 的公开仓库说明区分了构建工具与上游生成的应用包。讨论此类桌面应用时，我们也应按真实范围解释可检查的内容，而不把公开仓库、完整源码和可复现发行混为一谈。AlphaBiz 项目说明

开发者可以从补齐一份发行证据清单开始；用户则可以先检查自己最常用应用的一个下载文件。欢迎在 AlphaBiz Discussions 交流你希望发行页提供哪些验证信息。