mirror of
https://github.com/pgsty/minio.git
synced 2026-09-22 02:38:29 +03:00
Feng Ruohang
40 lines
4.8 KiB
Markdown
40 lines
4.8 KiB
Markdown
已完成独立复核：读了三份改动文件在 HEAD 的实际内容、`putOptsFromHeaders` 全函数与两条返回路径、`CopyObjectHandler` 的默认加密与标签排序段、`reconcileStoredObjectTags` 的三处生产调用点，以及全部指定日志与证据文件。
|
||
|
||
# R4 实现复核结论
|
||
|
||
**Verdict: GO_WITH_NONBLOCKING_NOTES（0 阻断项）**
|
||
|
||
- 复核 HEAD：`dbcf8dec589deb5d91e17d295cb70997635f5b55`
|
||
- 代码/测试 diff SHA-256（按提供值记录）：`c8cd6648f8ecea835ec74a038cdeaa82acaa3f36250395f97ead3260dc2fc0a5`
|
||
- 本会话无 shell，未重算该哈希；改为逐行比对 diff 与工作树三份文件，内容完全一致（`cmd/object-api-options.go`、`cmd/object-api-options-replication_test.go`、`cmd/object-copy-replication-tagging_test.go`）。
|
||
|
||
## 核验到的事实
|
||
|
||
- 生产改动确为一个字段 + 相邻注释：`cmd/object-api-options.go:459` 的 `ReplicationSourceTaggingTimestamp: taggingtimestmp`，变量来自 `:419-425` 已解析值，与非 KMS 路径 `:473` 对齐。未动解析、信任判定、KMS key/context、返回结构。
|
||
- 影响面封闭：全仓该字段唯一消费点是 `cmd/object-handlers.go:1820`（COPY 标签排序）。PUT/POST/multipart 虽同经 `putOptsFromReq`，但无消费者，故不可能回归——与 R4/R5 切分一致。
|
||
- 三条 KMS 触发路径真实可达：`object-handlers.go:1428-1433` 在 `copyDstOpts`（`:1454`）之前套用目的端默认；`bucket-sse-config.go:139-151` 在 `nil 配置 + AutoEncrypt` 与桶默认 KMS 两种情况下都写入 `aws:kms`，因此 explicit / auto / bucket 三种模式均进入 KMS 分支。
|
||
- 回归证明成立：`baseline-final.log` 用 `-overlay` 换回未修复 constructor，失败面精确为「trusted × 有效标签时间戳 × SSE-KMS / SSE-KMS-context」和 6 个 KMS COPY 子测试（`tags="key=old"`、`kms=true`、HTTP 200），`none`/`SSE-S3`/`SSE-C`/非 trusted 全通过。修复后 `focused.log:194-204` 全 PASS。
|
||
- 测试确实覆盖被要求的维度：信任边界（trusted=false 时 mtime/ETag/三时间戳全归零）、错误路径（trusted + 畸形值必须报错且错误串含头名）、SSE 序列化回环（KMS keyID/context 原样还原）、磁盘终态（每事件 `obj.GetObjectInfo` 读真实盘）、版本一致性、签名 GET 明文可读。全局 `GlobalKMS`/`globalAutoEncryption`/`set.getDisks` 均 defer 还原。
|
||
- `race` exit 0、`vet` 空输出、`golangci-lint` 0 issues，均记录了与 HEAD 一致的三文件哈希。
|
||
- 未发现 `verification.md` / `verification.json` / `consensus.md` 中与日志矛盾的陈述。（评审者版本/模型/effort 这类 provenance 声明不在我可验证范围，未作背书。）
|
||
|
||
## 发现清单
|
||
|
||
| ID | 内容 | 阻断 |
|
||
|---|---|---|
|
||
| IMPL-01 | 单字段修复正确且充分，位置、变量、注释与 `:473` 语义一致 | 否（确认项） |
|
||
| IMPL-02 | 基线失败/修复通过的判别力成立，对照组不误报 | 否（确认项） |
|
||
| IMPL-03 | KMS 字面量相对 `getDefaultOpts` 仍缺 `ProxyHeaderSet`/`ProxyRequest`/`Speedtest`（`object-api-options.go:40-44` vs `:449-460`）。R4 范围外，已登记为 R4-06 | 否，不设为新合并门槛 |
|
||
| IMPL-04 | `metadata-directive: REPLACE` 下 `getCpObjMetadataFromHeader`（`:1143-1156`）返回全新 map，故 `:1818` 的 `lastTaggingTimestamp` 为空、`:1822` 解析失败使 handler 侧比较恒「incoming 胜」；真正的 stale 拒绝发生在写锁内的 `reconcileStoredObjectTags`（`erasure-object.go:1312-1315`）。测试终态断言仍正确，文档 R4-07 已明示此分工 | 否（R5 上下文） |
|
||
| IMPL-05 | 测试卫生：`bucket-kms` 模式写入的 `bucketSSEConfig` 未还原，仅因它是最后一个 mode、且 `ExecObjectLayerAPITest` 每后端重建对象层并 `resetTestGlobals()` 才安全；后续若在其后追加 mode 会继承默认 KMS | 否 |
|
||
| IMPL-06 | `object-api-options-replication_test.go:35` 局部变量名 `context` 遮蔽标准包名（本文件未导入该包），纯观感 | 否 |
|
||
| IMPL-07 | `focused.log` exit 1 的唯一失败是既有 `TestAPICopyObjectReplicaRetentionRemovalUnderBucketKMS`（`replication-trust_test.go:1284`，"Storage reached its minimum free drive threshold"），属本机磁盘余量环境问题，非本次引入；容量 overlay 是测试专用、未提交。新增 COPY 测试自带 `tagTestCapacityDisk` 包装，不受该阈值影响 | 否 |
|
||
|
||
**没有发现阻断性正确性问题。** 生产语义、存储格式、API 与既有排序规则均未改变，无任何既有测试断言旧（缺陷）行为。
|
||
|
||
## 合并适配性
|
||
|
||
`dbcf8dec5` 直接位于实时 main `9ebe81c1b` 之上，可快进合并。按仓库 CI 通过为前提，本实现适合合入 main。
|
||
|
||
*（我未运行任何测试，也未查询 GitHub；以上仅基于源码阅读与所提供日志。）*
|