
## 背景

fibemate 是后量子密码全栈工程验证平台，实现 ML-KEM-768（FIPS 203）、ML-DSA-65（FIPS 204）、SLH-DSA-128s（FIPS 205）与国密 SM2/SM3/SM4。仓库的 GitHub Actions 门禁矩阵覆盖 CI、CodeQL、Scorecard、KAT 回归、nightly、DCO、SBOM 七条链路。

门禁矩阵的语义需要明确：每条链路返回退出码 0，表示该链路在当前运行环境里通过了它定义的检查集合。**这不等于交付物正确。** 两者之间存在一个常被忽略的隔离层——Working Tree（工作树）与 Commit（提交对象）的隔离。

## 现象剖析

2026-10-29 的一次交付暴露了这个隔离层。`git reset --hard` 返回 0，工作副本已移动到目标提交。站点既有检查状态合规。公网服务的字节与仓库提交对象不一致。`AUDIT.md` 第 4 节标题记录了这个状态：**部署状态合规，但字节是错的。**

同一次仓库治理里，`git status` 报告 519 个未跟踪文件。CHANGELOG 记录：
> Git cleanup: 519 untracked → 0, .gitignore hardened

519 个文件不进任何提交对象，但占用磁盘。测试运行器从磁盘加载文件，不区分跟踪状态——这是 Working Tree 与 Commit 隔离的工程原理。

另一条门禁的覆盖域盲区记录在 `.github/workflows/ci.yml` 的 cbom job 注释里。fibemate 的 CBOM 漂移检查与 schema 校验以前只在 `release.yml` 里运行。PR 阶段不跑这两条，PR 视角里 CBOM 门禁就是状态合规。PR 可以改坏 CBOM 生成器，直到发版才暴露。这不是门禁出错，是门禁覆盖域与 CI 读取域不重合。

## 根因定位

Git 仓库有三个独立的字节来源：Commit 对象（`git cat-file` 读取的内容权威）、Index（暂存区）、Working Tree（磁盘文件）。三者在 Windows checkout 上经常不一致。

`.gitattributes` 配置 `* text=auto eol=lf`。文本文件 checkout 时被重写为 LF。封存产物用 `-text` 标记保留原始字节。CI 的文本级检查读取工作树。工作树已经被重写。检查看到的字节与提交对象不同。`AUDIT.md` 记录了第一版交付门禁的失败：
> The first version of this check hashed the working tree and reported drift on files the site served correctly.

哈希工作树会对正确服务的文件报漂移。哈希提交对象才与公网可比。**工作树是提交对象的渲染，不是提交对象本身。**

未跟踪文件构成第二类污染。一个落在 `experimental/` 下的实验实现被 `src/` 无条件 `require` 时，生产入口实际加载的是未提交的代码。CI 校验通过，因为测试跑了。**被测对象不在提交对象里。**

## 工程解法

三道闸分别守住三个隔离边界。

### 闸一：脏工作区拒绝部署

部署脚本在 `git reset --hard` 前检查工作区洁净度。`docs/deployment.md` 的部署前置条件：

```bash
cd "$REPO_DIR"
if [ -n "$(git status --porcelain)" ]; then
  echo "工作区有未提交改动，停止部署" >&2
  exit 1
fi
```

`git status --porcelain` 输出非空，意味着工作树与提交对象或暂存区存在差异。部署在此中止。同一脚本在部署完成后再次检查脏工作区文件数：

```bash
echo "脏工作区文件:  $(cd /opt/fibemate-repo && git status --porcelain | wc -l)"
```

### 闸二：实验代码编译期隔离

`scripts/check-experimental-isolation.cjs` 在 CI 的 bom-check job 里强制验证。规则：`src/` 下的 `.js` 文件不得无条件 `require('...experimental/...')`。核心检测逻辑：

```javascript
// 检测 require experimental
const reqMatch = trimmed.match(
  /require\s*$\s*['"]([^'"]*experimental[^'"]*)['"]\s*$/);
if (!reqMatch) continue;

// 允许：if (flags.XXX) 条件块、try/catch 防御性加载、三元表达式
if (!isConditional && !isTry && !isTernary) {
  console.error(`VIOLATION: ${relPath}:${lineNum}: unconditional require of experimental module`);
  violations++;
}
```

无条件的 `require` 即判违规，退出码 1。实验代码进不了生产入口，除非显式受 flags 门控。这道闸把"未跟踪文件渗入生产入口"的风险在编译期拦截。

### 闸三：可复现构建双跑比对

`.github/workflows/repro-build-check.yml` 在同一 commit 上把生成器跑两次，比 SHA-256：

```yaml
- name: Build #1
  run: node scripts/gen-sbom.js "$RUNNER_TEMP/b1.cdx.json"
- name: Build #2
  run: node scripts/gen-sbom.js "$RUNNER_TEMP/b2.cdx.json"
- name: Compare SHA256 + attribute
  env:
    REPRO_STRICT: "0"    # "1" = 不一致即红
  run: |
    h1=$(sha256sum "$RUNNER_TEMP/b1.cdx.json" | cut -d ' ' -f1)
    h2=$(sha256sum "$RUNNER_TEMP/b2.cdx.json" | cut -d ' ' -f1)
    if [ "$h1" = "$h2" ]; then echo "verdict=DETERMINISTIC OK"
    else echo "verdict=NON-DETERMINISTIC WARN"; fi
```

生成器已修为确定性：serial 内容派生，timestamp 由 `SOURCE_DATE_EPOCH` 派生。两次构建字节一致是确定性的必要条件，不是充分条件。它只证明同一 commit 同一 toolchain 下无随机性渗入。`REPRO_STRICT=1` 时不一致即判红，默认 warn 是因为非确定性是发现信号，不一定是交付阻断。

## 代码落地：字节权威的正确读取方式

三道闸共享一个底层原则——**读 Commit 对象，不读工作树**。`git ls-files -s` 取提交对象里的 blob SHA，`git cat-file --batch` 取该 blob 的原始字节。这条链路不经过工作树，Windows checkout 的换行符重写对它无效：

```javascript
// 取提交对象里的 blob SHA（不读磁盘）
const raw = git(repo, ['ls-files', '-s', '-z', '--'].concat(rels));
// 按SHA批量取原始字节
const batch = git(repo, ['cat-file', '--batch'], shas.join('\n') + '\n');
```

任何在 CI 里做字节比对的脚本，若用 `fs.readFileSync` 读磁盘文件作为期望值，在 Windows checkout 上都会对正确交付的文件报漂移。**期望字节必须来自 `git cat-file`。**

## 边界声明

上述三道闸覆盖工作树污染、未跟踪文件渗入、生成器非确定性三类问题。它们不覆盖：
- 提交对象本身的正确性。commit 进了错误代码但工作区洁净，闸仍通过。
- toolchain 漂移。Node 版本跨跑差异，由 `actions/setup-node` 固定版本缓解，不消除。
- 侧信道与标准安全性。字节一致不蕴含常数时间性。

**校验通过是状态合规，不是正确性证明。** 交付门禁的最终判据是公网字节与提交对象一致，这一点在下一篇展开。

---
**项目仓库**：[github.com/Lennonhaha/fibemate](https://github.com/Lennonhaha/fibemate)
**预印本（方法学）**：Tianhe Liu. Deterministic but Wrong: Why Behavior-Based Tests Miss Structural Errors in Keccak-f Implementations. Zenodo, 2026-10-25. [https://doi.org/10.5281/zenodo.23637405](https://doi.org/10.5281/zenodo.23637405)
**预印本（工程总览）**：Tianhe Liu. Engineering Verification of PQC: A Case Study on Formalizing VWZ in Isabelle/HOL and Supply Chain Integration (CBOM). Zenodo, 2026-10-30. [https://doi.org/10.5281/zenodo.23808518](https://doi.org/10.5281/zenodo.23808518)




fibemate 是后量子密码全栈工程验证平台，实现 ML-KEM-768（FIPS 203）、ML-DSA-65（FIPS 204）、SLH-DSA-128s（FIPS 205）与国密 SM2/SM3/SM4。仓库的 GitHub Actions 门禁矩阵覆盖 CI、CodeQL、Scorecard、KAT 回归、nightly、DCO、SBOM 七条链路。

上下文隔离与构建确定性：为何 CI 的"校验通过"依然不可信

CI 校验全过，线上字节却错了？这并非偶然，而是 Git 工作树与 Commit 对象的底层隔离在作祟。本文带你复盘一次真实的构建交付事故，用三道底层闸门（脏工作区拦截、编译期隔离、双跑比对），让你的“校验通过”真正等于“交付正确”。

人工智能

fibemate PQC平台通过三道工程闸门解决部署字节与Git提交对象不一致问题：脏工作区拒绝部署、实验代码编译期隔离、可复现构建双跑比对，核心原则是读Commit对象而非工作树，确保CI校验与公网交付字节权威一致。

后量子密码

代码解释

JavaScript

Windows

GitHub

国密

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

上下文隔离与构建确定性：为何 CI 的"校验通过"依然不可信-腾讯云开发者社区-腾讯云

上下文隔离与构建确定性：为何 CI 的"校验通过"依然不可信

上下文隔离与构建确定性：为何 CI 的"校验通过"依然不可信

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐