edit | blame | history | raw

B站认证扩展标准托管加载 V005：不可变审计节锚点修订

创建人员：dev.developer.project.secondary / infodev-2
事项：DEV-PROJECT-INFO-BILI-AUTHENTICATED-SESSION-DOWNLOAD-20260805-001
需求：REQ-BILI-DYNAMIC-COLLECTOR-20260804-001
唯一审核员：dev.reviewer.project / inforev
基础合同：V003 17715/1EC7F6D8D6CD6AA9BEE5F5696D1CB578514CA3C61ADA838777093C8EFEF2C2F1 + V004 21074/6E2B2AEDD2A432889ACD5314B5AD1C93B923D937E628434AE952A303A2BE8486
触发审核：DEV-AUDIT-PROJECT-INFO-BILI-AUTHENTICATED-EXTENSION-MANAGED-LOAD-CANDIDATE-PACKAGE-REVIEW-20260810-001，结论 HOLD/1。

本文件只修订 source approval 对实现审核的生命周期绑定。V003+V004 的 Web Store、exact-nine payload、扩展 ID、秘密边界、policy 事务、安装恢复和所有真实动作门禁继续冻结；发生文字冲突时仅本 V005 的 source approval schema 与审计锚点规则优先。

1. 问题与冻结前像

现有 schema 1 implementation_review={audit_id,audit_path,audit_bytes,audit_sha256,verdict} 把批准绑定到整份 append-only dev-doc/开发审计报告.md。候选包审核必须追加新审计节，导致 whole-file bytes/SHA 合法变化，builder 与 installer 随即 E_BUILD_CONTRACT。候选 ZIP 本身的9项身份、CRC、扩展 ID、哈希和秘密边界均已通过，但批准链不可继续消费。

冻结历史，不作修改、覆盖或复用：

  • 候选 ZIP：20072/96A7FA513EA136A63A15AC1654D4918F368B3D2CD195F381536C1A6B138D2E91
  • 候选 receipt：2165/4D90F74D7FE0DBDF197499AC48040733D1C4A885262C7B6734BC2A7F1284596F
  • 历史 source approval：2261/F54924D29A1390538C7BBB1BB30A5F2E2FC4A7AFB7F935E1184B8C6D91D22ED0

V005 设计 PASS 前，builder、installer、contract、README、测试和候选输出全部冻结；不得创建新候选。

2. 唯一修复路径

2.1 source approval schema 2

新 source approval 顶层 exact keys 沿用 V004，但 schema 必须为 2。旧 schema 1 在 builder 与 installer 的任何业务输出、copy、registry、pending 或 receipt 前失败关闭，不能自动迁移或 fallback。

implementation_review exact keys 改为：

audit_id
audit_path
audit_section_format
audit_section_bytes
audit_section_sha256
verdict

固定值与格式：

  • audit_path=dev-doc/开发审计报告.md
  • audit_section_format=mbx-markdown-level2-section-lf-v1
  • audit_id 必须匹配生产前缀 DEV-AUDIT-PROJECT-INFO-BILI-AUTHENTICATED-EXTENSION-MANAGED-LOAD-；测试仅内部 adapter 可用 DEV-AUDIT-TEST-MANAGED-LOAD-
  • audit_section_bytes 为正整数
  • audit_section_sha256 为64位大写十六进制
  • verdict=PASS

schema 2 不再出现或接受 audit_bytes、audit_sha256，产品代码和合同也不得比较整份审计文件的长度或 SHA-256。approval 外层 path/bytes/SHA、reviewer role/scope/status、contract、原 source manifest、managed source tree 和 exact-nine payload 绑定继续不变。

2.2 规范审计节算法

builder 与 installer 必须消费 managed-load-contract.json 中同一份 implementation_audit_section_contract，不得各自冻结不同常量。算法固定如下：

  1. 对 audit_path 及父链做 lexical/no-reparse 检查；目标必须是普通文件。
  2. 严格 UTF-8 解码；拒绝 BOM、NUL、CR 和无效 UTF-8。本合同只接受 LF 行尾。
  3. 审计节起始行必须是唯一的 exact ## {audit_id}；0次或多次均失败。
  4. 节范围从该标题行开始，到下一个行首 exact ## 二级标题之前，若没有后续标题则到 EOF。
  5. 仅移除节尾连续空行；其余字符、空格和行序保持不变。把剩余各行用单个 LF 连接，并追加恰好一个最终 LF，得到 canonical section bytes。
  6. 复算 canonical bytes 长度和 SHA-256，与 approval 的 audit_section_bytes/audit_section_sha256 exact 比较。
  7. canonical section 中必须各有一行 exact - verdict=PASS/0、- blocking_findings=0，并包含本 task ID 和当前 managed_load_source_tree.tree_sha256。

因此，在原节之后合法追加一个或多个新的 ## ... 审计节不会改变 canonical bytes；对原节的修改、删除、截断、同 ID 复制、在原节内部无标题插入内容、ID/hash/bytes 漂移都会失败关闭。

3. 模块改动边界

只允许修改：

  1. build_webstore_upload.ps1：共享语义的审计节提取/校验；schema 2 source approval；删除 whole-file identity gate。
  2. install_managed_extension_policy.ps1：实现与 builder 等价的同合同校验，且仍在 copy/HKCU/pending 前执行。
  3. managed-load-contract.json：schema 2、审计节格式/标题/规范算法/required lines；source approval exact child keys。
  4. test_managed_load.py：仅聚焦本修复及既有回归。
  5. README.md、实现证据、worklog 和 append-only 开发账本：纠正生命周期说明和测试证据。

不得修改冻结的 bili_authenticated_extension/ 17文件、bridge、worker/runtime、历史候选和 reviewer 私有批准。developer 不得创建正式 source approval。

4. 验收矩阵

所有反例均在 TemporaryDirectory 的受控复制树内执行，生产 CLI 不暴露测试注入参数。

4.1 两个消费者的非真空正例

对 builder -ValidateOnly 与 installer -ValidateOnly 分别证明：

  1. schema 2 approval 绑定唯一 PASS 审计节时通过。
  2. approval 生成后，在审计文件尾部追加一个和多个无关 ## ... 节，原 approval 仍通过。
  3. 通过时 builder 不创建输出；installer 不 copy、不建 pending/receipt、不写 registry。

4.2 两个消费者的失败关闭反例

至少参数化覆盖：

  • 原审计节任一字符修改、删除、截断；
  • 原审计 ID 标题复制；
  • approval 的 ID、section bytes、section SHA、format、verdict 漂移；
  • 审计节缺 required line、task ID 或 source tree hash；
  • stale schema 1 / stale source tree / cross-source approval；
  • CRLF、BOM、NUL、无效 UTF-8、audit path 或父链 reparse；
  • 在原节尾部但下一个二级标题之前插入未绑定内容。

断言均为 SAFETY_STOP/exit 3 和固定 E_BUILD_CONTRACT；builder output absent，installer copy/HKCU/pending/receipt 全部 absent，错误输出不包含外部正文或秘密值。

4.3 静态与回归

  • 产品代码、contract、README 和正式 schema 中 audit_bytes/audit_sha256 整文件绑定匹配数为0；测试可保留历史负例字面量。
  • PowerShell parser、strict JSON、UTF-8/no BOM/no trailing whitespace PASS。
  • 当前目标测试、项目回归与 governance OK/projects1/warnings0。
  • 历史候选4个核心文件 bytes/SHA 在 Stage A 前后不变；新候选数量仍为0。

5. 审核与两阶段门禁

  1. V005 先沿原 inforev 链做 audit-anchor-only 设计复审。PASS 前不得改产品代码。
  2. 设计 PASS 后实施本文件第3节，运行第4节离线测试，再提交同链 source/implementation 复审。
  3. 只有实现 PASS/0 且 reviewer 在源码/测试/输出树外创建一个绑定新 schema 2、new source tree 和 canonical implementation-audit section 的 source approval，Stage A 才结束。
  4. Stage B 只有在上述门禁满足且 project.admin 后续调度一个此前不存在的输出根后，才允许构建恰好一个新候选；当前 HOLD 候选不得复用或发布。
  5. 新候选仍须同链 hash-only package identity/release-gate 审核。正式 Web Store release approval 只能在未来受权上传/发布证据存在后形成，本阶段不得创建。

6. 零动作边界

设计、实现、测试和 source 审核全过程：Web Store upload/publish、release approval、policy/HKCU、安装/启用、Chrome/Cookie/session、network/download、真实媒体、F:\video、formal ana-data、转写和 BV1HA3o6oEJJ runtime 均为0。不得新建任务、owner、reviewer 或审核链。