HarperZ9/emet

# EMET [](https://github.com/HarperZ9/emet/actions/workflows/conformance.yml) EMET 是一个用于 AI 监管以及源/视图一致性检查的小型外部见证者。 它会检查到达模型的字节是否仍然与它们声称所代表的源相匹配，然后报告三种经过刻意限制的结论之一：`MATCH`、`DRIFT` 或 `UNVERIFIABLE`。 它的存在是为了填补构建溯源工具自身无法覆盖的空白：系统在带内为自身担保、呈现的视图偏离了源，或者监控器读取的文件与实际运行的文件不同。信任来自于重新推导 —— 相同的字节，相同的答案 —— 而非来自于权威。这里没有 `TRUSTED` 结论。 `emet` 在希伯来语中意为“真相”。 ## 目录 - 一个仅使用标准库的 Python 参考实现 - `membrane.py` / `organs.py` / `monitor.py` / `corpus.py`，约 520 行代码，无外部依赖。 - 一个从零编写的 Rust 第二实现 - `impl/rust/emet.rs`，不使用任何 crates。 - 一个净室开发的 Node.js 第三实现 - `impl/js/emet.js`，仅使用内置模块（无 npm）。 - 一份规范性规范草案、一套语言无关的一致性测试套件、一个 STRIDE 威胁模型，以及一个 in-toto 证明适配器。 - 一个带版本号的标记语料库（`conformance/markers.corpus`），所有三个实现都能完全一致地加载并重新推导它。 - 所有三个实现都在每次推送的 CI 流程中通过了相同的 19 个一致性向量测试 —— 包括字节哈希核心、标记路径和审计链（写入与验证）。 ## 复现 ``` git clone https://github.com/HarperZ9/emet && cd emet python conformance/run.py membrane.py # reference implementation: 19/19 ( cd impl/rust && rustc -O emet.rs -o emet ) # build the second implementation python conformance/run.py impl/rust/emet # second implementation: 19/19 python conformance/run.py impl/js/emet.js # third implementation (Node.js): 19/19 ``` ## 使用 ``` python membrane.py selftest # re-derive its own hash python membrane.py anchor ... # pin raw-byte hashes python membrane.py verify ... # MATCH / DRIFT / UNVERIFIABLE python membrane.py coherence # is a presented view faithful to source? python membrane.py refuse # detect + strip in-band authority claims python membrane.py corroborate # read-path-diverse agreement python membrane.py audit # recompute the tamper-evident log chain ``` ## 证明面（Proof-surface）用途 EMET 是证明面流水线中的见证点： ``` source bytes -> presented view -> witness verdict -> reviewer handoff ``` 当仓库、报告、面向模型的 prompt 或生成的视图需要一个小型的外部检查，以确认所呈现的材料仍然与它声称所代表的源相匹配时，就可以使用它。 快速审查清单： - `MATCH` 表示被检查的材料重新推导出了预期的字节级结果。 - `DRIFT` 表示呈现的视图或被检查的字节发生了变化。 - `UNVERIFIABLE` 表示见证者无法进行比对。 - 这里没有 `TRUSTED` 结论。 这使得 EMET 可作为发布就绪和尽职审查的工件：它可以展示被比对的内容以及得出的结论，而无需要求见证者成为权威。 可选的 `adapters/proof_surface_receipt.py` 适配器会为证明索引和发布就绪工作流生成紧凑的 JSON 见证回执。它独立于 EMET 核心存在，不会改变受控的标准输出（stdout）、签名、强制执行或驱动边界。 ## 它不会做的事 它只报告事实。它不能给出 `TRUSTED` 结论，不决定模型是否安全，运行在被审计对象之外，并且绝不编辑、签署或阻止任何事物。 这些约束是其核心意义所在，而非缺陷 —— 参见 [SPEC.md](SPEC.md) 第 6 节。 ## 状态 1.0 版本之前；规范为草案（v0.2.0-draft）。字节哈希核心、标记路径（一个在所有实现中完全匹配的单一版本化语料库）以及审计链（写入和验证）均能在三种语言中重新推导得出，并在 CI 中进行了检查（19 个一致性向量，覆盖所有三个实现）。有一点需要坦诚说明而非掩盖：在某一方面，其可重推导性**尚未得到完全证明**： - Rust 和 Node.js 实现属于同一作者的净室开发，并非独立完成。 - SPEC 第 12 节设定的实际标准 —— 一份通过所有向量测试的*独立的、不同作者的*实现 —— 尚未达成；且根据第 12 节，在此之前任何一方都不应将可重推导性视为已证明。 这份来自不同作者的实现是下一步计划，规范中对此有明确说明（第 12 节）。 对于一个仅以可复现性为凭证的工具而言，夸大的声明只会自我反驳 —— 因此，目前的声明范围严格限定为 CI 当今所能复现的内容。 ## 呼吁独立实现 EMET 唯一的凭证就是可复现性：相同的字节，相同的结论。目前已有三个实现（Python 参考实现 + Rust + Node.js）在 CI 中对全部 19 个一致性向量达成一致 —— 但它们都出自同一位作者，因此这种一致性仅表明该规范是*可实现的*（通过其纯文本在三种语言中实现），而尚未证明它是*可独立重推导的*。 因此，影响力最大的贡献并非另一种语言的实现，而是一份**由不同作者编写的、仅依据 [SPEC.md](SPEC.md) 完成的实现**（而非通过阅读现有代码），该实现可使用任何语言，并能够通过 `conformance/vectors.json`： ``` # 构建你的实现，然后： python conformance/run.py ./your-emet # expected: CONFORMANCE 19/19 ``` 当你的实现与规范出现分歧时，**说明规范是错误的** —— 请提交一个 issue；这些分歧正是这项工作的核心意义所在。（Node.js 实现已经这样做了：仅依据规范构建它，暴露出标记的*数量*未被固定的问题 —— 现已在 SPEC 第 16 节和 `refuse-repeated-marker-occurrence-count` 向量中对其进行了固定。）一份来自不同作者的实现，能将可重推导性从*口头声明*转化为*实际证明*（SPEC 第 12 节）。请在 [讨论区](../../discussions) 认领你想使用的语言，以免重复劳动。 ## 文档 [SPEC.md](SPEC.md) · [RATIONALE.md](RATIONALE.md)（解释 EMET 形态的缘由，源自第一性原理推导） · [conformance/](conformance/) · [THREAT-MODEL.md](THREAT-MODEL.md) · [COVERAGE.json](COVERAGE.json) · [SECURITY.md](SECURITY.md) · [CONTRIBUTING.md](CONTRIBUTING.md) MPL-2.0。

标签：GNU通用公共许可证, MITM代理, Node.js, Python, Rust, 一致性验证, 人工智能监督, 可视化界面, 多语言实现, 数据完整性校验, 无后门, 网络流量审计, 逆向工具