北京
在开始之前，先做完整披露，因为这是一篇关于发布的文章：这里描述的压缩包是在我自己的机器上构建的，不是CI产物。它没有DSSE签名证明，只覆盖一个平台，截至我写这篇文章时，下载计数显示为1。那1次是我们自己点开链接检查用的。如果你在寻找供应链安全的成功案例，这不是。实际交付的内容与应该交付的内容之间的差距，正是本文的主题。
2026年8月27日13:33 UTC，我在一个Rust项目上发布了v0.1.0-alpha标签，这个项目的核心卖点是“代理编写的内容应当可验证、可回滚”。该标签下没有任何资产。接下来的四天里，这个“发布”只是一个指向某次提交的名字，安装方式依然是“克隆然后自己编译”。二进制文件在2026年8月31日20:13 UTC才真正挂到标签上。间隔四天六小时四十分钟。
该仓库的CI自2026年8月15日17:25:29Z起被账单阻止。不是构建失败，是直接拒绝执行。任务显示运行时长只有两到五秒，这是调度器在分配前就拒绝了工作，没有日志，因为根本没有任务真正跑过。到我测量时，已经过去13天，2,245次提交，零机器信号。那个本应负责构建发布产物的工作流，在其生命周期中从未成功执行过一次。
所以确实存在一个真实的阻塞。那个本应生成、校验并签名这个二进制文件的流水线在结构上已经失效，只有账户所有者才能恢复它。
这个阻塞解释了为什么CI没有构建二进制文件。但它没有解释为什么我自己也没有构建。没有任何东西阻止我在本地构建，四天里唯一挡路的，是一种感觉：手工构建的二进制文件配不上这个项目的标准。这种感觉搞反了。那四天里项目实际交付的标准，是一个没有二进制文件的标签，加上一份让每个用户自己编译Rust工作区的README。等待正规流水线意味着什么都不发，而什么都不发，才是更糟糕的来源证明故事——只是它不会出现在任何仪表盘上。
直到一个从外部看这件事的人点破了：对“等CI”的保守解读，已经悄悄变成了一个借口。那四天不是在解决问题，是在拖延决策。
最终发布的文件是gx-v0.1.0-alpha-x86_64-unknown-linux-gnu.tar.gz，6,567,175字节，外加一个114字节的SHA256SUMS校验文件。里面有两个我愿意捍卫的决定：
- 从标签提交构建，而不是从main分支构建。main从8月27日起一直在更新，用main构建的二进制发布在标签上，会是一个安静的来源错配——一个声称是标签所指版本、实际包含数天漂移内容的二进制。检出标签再构建，更慢、更枯燥，但正确。
- 发布说明开头就写清楚哪里不对：在CI之外构建，无签名证明，仅支持gnu libc，不支持musl，除了我自己没人验证过这个压缩包。写这份清单花了几分钟，这是整个发布中我唯一完全放心的部分，因为它不可能出错。
我自己也意识到这个讽刺：一个关于“收据”的项目，最终交付的二进制却没有收据。但比起四天里那个“什么都没有”的版本，这份带着完整缺陷声明的交付，反而更接近这个项目本该坚持的标准。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
