构建与签名

EvoX Desktop、Linux 产物、内嵌 sidecar、Evolver npm 包和文档网站由不同流水线负责。一个对象构建成功不能替代其他对象的产物与签名检查。

当前平台产物

Linux GNU 内核产物属于内核发布矩阵，不代表提供 Linux 桌面安装包。桌面内嵌 sidecar 必须核对对应版本的内核 bundle。

构建记录

每个产物应能回到以下信息：

source repository and revision
release version and channel
build environment and toolchain
target platform / architecture
artifact filename and size
SHA-256
signature identity and verification method

签名边界

签名密钥只能由所属发布系统使用，不进入仓库、普通日志、构建缓存或文档。构建者与最终晋级者应尽量分离；至少要由第二人或独立流水线验证下载字节和签名。

签名、摘要和来源各自证明什么

源码提交说明构建基于哪一份代码；构建记录说明使用了哪些依赖、工具链和目标；摘要用于确认核对的是同一份字节；签名与平台验证用于核对发布身份及平台接受条件。它们互相补充，不能只保留其中一个结果。

例如，文件的 SHA-256 与候选记录一致，说明取得的文件没有偏离候选字节，但不证明签名身份正确。平台签名通过，也不证明产物来自预定提交。发布交接应让验证人员把源码、构建任务、签名产物和最终下载逐项关联起来。

场景：同一版本需要重新构建

先确认重新构建是修复构建环境、签名步骤还是软件代码。代码变化必须对应新的明确来源；即使版本字符串相同，也不能把新文件当成此前已验证的字节。重新签名或重新打包后，按最终文件重新计算摘要并执行验证。

已经发布的不可变产物不得覆盖成另一份文件。失败产物保留记录，修复通过所属仓库的发布流程生成新的可追溯候选。验证交接同时说明哪些证据仍适用、哪些步骤已经重新执行，避免沿用旧报告造成来源断裂。

构建顺序

1. 固定源码修订、依赖锁和工具链。
2. 分平台构建，不用一个平台的成功推断其他平台。
3. 签名并生成候选清单数据。
4. 上传不可变产物，再交给独立验证步骤重新下载。
5. 验证本次交付平台后写入候选记录；公开桌面更新指针须等同号 macOS 双架构和 Windows x64 齐套。

不同发布对象

文档网站部署只说明网页已更新；它不会生成或验证 EvoX 安装包。Evolver npm 包发布也不等于 Desktop 或 sidecar 已更新。发布台账应分开记录对象、仓库、版本和负责人。

交给验证环节的材料

为每个平台提供固定源码 SHA、依赖与内核 bundle 版本、构建任务记录、安装包最终地址、大小、SHA-256 和签名校验结果。候选清单必须对应已经签名的最终字节；签名后重新打包或替换文件，要重新计算摘要并重新验证。

构建、签名或上传任一环节失败，都保留失败记录并阻止该产物交付。使用所属仓库当前发布工作流处理修复，不在文档中拼装通用签名命令。完成标准是验证人员能从记录取回同一份产物并独立复核来源和签名。

相关页面

• 签名清单
• 验证与晋级

EvoX 文档 · 开发者 · 软件发布维护