SILO 一年回顾：相比上游 MinIO，我们到底干了什么？

2025 年 10 月 15 日，MinIO 发布了最后一个公开开源版本 RELEASE.2025-10-15T17-29-55Z（提交 9e49d5e7a648）。随后两个月里，上游先宣布进入“维护模式”，接着删除了 minio/console 仓库，最终在 2026 年 2 月将主仓库彻底归档，把所有后续 CVE 修复与维护留在商业版 AIStor 中。

到 2026 年 10 月 26 日，SILO 打下 RELEASE.2026-10-26T00-00-00Z 标签（提交 c3ad836aed0d）。整整一年（376 天），服务端主仓库合入了 604 次提交，连同配套的 silo-console、mcli 与 silo-pkg 一起，走完了一轮完整的工程演进。

很多用户问过同一个问题：从 MinIO 分叉出来的这一年，SILO 到底只是换了个名字打安全补丁，还是真的在修底层问题？跟上游最后那个版本相比，实质差异到底在哪？

先把核心结论摊在桌面上：SILO 没有改动 MinIO 的纠删码存储引擎、xl.meta 磁盘格式与基本读写仲裁规则；这一年的全部工程火力，都花在安全边界、S3 协议与校验和正确性、复制与生命周期收敛、失败写入与多池保护，以及恢复完整的管理控制台与客户端体验上。

同时，有一说一，下面这些边界我们同样在文档与发布验收里写得明明白白：

1. 没有引入分布式 fencing，也不能宣称解决了全部一致性问题。 租约过期或网络分区下的迟到写入仍可能发生；严格代际拒读、自动跨池读恢复、公开持久分段上传枚举（#79）、访问频率池间分层与多池覆盖亲和（#245）在实测暴露容量或可用性代价后均已撤回或延期。
2. 没有跑过两个固定版本的全集群对等性能基准。 我们有局部热路径的微基准与摊销开销实测，但绝不凭空编造“整体吞吐提升 X%”的数字。
3. 磁盘格式兼容不等于支持任意混跑或无脑降级。 新的 IAM 持久化撤销状态（siloParentRevocation）与复制墓碑需要参与节点协调升级。

下面按模块逐一拆解这一年里 SILO 具体改了什么、为什么这么改，以及每项改动背后的代码证据与使用边界。

1. 基线与产品栈：什么变了，什么没变

本次对比的精确基线是上游 MinIO 最后一次公开发布与 SILO 2026 年 10 月统一维护批次：

• 上游基线：minio/minio RELEASE.2025-10-15T17-29-55Z（提交 9e49d5e7a648f00e26f2246f4dc28e6b07f8c84a，2025-10-15）。注：上游在停发 Release 到 2026-02-02 归档前还合入过 9 个未发版提交（如 fa18589d1c 的 POST Policy 标签约束、18f97e70b1 的条件写读仲裁调整），这些提交不在 2025-10-15 正式版内，SILO 也通过独立路径完成了对应修复。
• SILO 目标版本：pgsty/silo RELEASE.2026-10-26T00-00-00Z（源码 c3ad836aed0d8a7d23c2e44a5eaa3009d08525e3），与 mcli / KES 20261026、Console v2.5.1、silo-pkg v3.15.2 联合发布。详见本批次发布日志与组件矩阵。

在 9e49d5e7a648..c3ad836aed0d 区间内，pgsty/silo 共有 604 个可达提交（涵盖功能与安全修复、回归测试、构建打包与文档工程）。下文按实际交付的运行时行为逐一归纳。

四组件协调维护栈

上游归档后，单靠一个服务端仓库无法交付完整的对象存储系统——因为服务端内嵌了 Console 前端与 mc 管理模块，又直接依赖共享策略与加密库。SILO 将维护范围收敛为四个协同演进的核心仓库（加可选外部密钥服务 KES）：

刻意保持不变的底层基石

为了确保现有 MinIO 部署能够原地替换为 pgsty/silo 而不触发数据重算或客户端改造，以下核心架构与协议层保持不变：

• 纠删码与 Bitrot 保护：底层仍采用 Reed-Solomon 纠删码与 HighwayHash256 分块校验。
• 基本读写仲裁规则：读仲裁仍为数据分片数 $K$；写仲裁在数据分片与校验分片不等时为 $K$，相等（如 8+8）时为 $K+1$（例如 16 盘 12+4 配置下读写仲裁均为 12，8+8 配置下读仲裁为 8、写仲裁为 9）。
• 磁盘格式与系统命名空间：xl.meta 格式版本保持 1.3，系统元数据目录仍为 .minio.sys，已有数据盘无需格式转换即可直接挂载。
• 线上协议与配置兼容：完整保留 MINIO_*、MC_*、CONSOLE_* 环境变量、/minio/health/* 健康探针、/minio/v2/metrics/* 与 /minio/metrics/v3 监控路径，以及 X-Minio-* 头部兼容（详情见兼容性总览与迁移指南）。

2. 安全、认证与授权：7 个 CVE 与 18 项安全边界加固

接手维护的第一道硬仗是安全漏洞。由于 SILO 保留了 github.com/minio/minio 模块路径，而上游发布 GHSA/CVE 时往往将受影响版本写成开放区间，许多安全扫描器会把所有历史漏洞一股脑报在 SILO 头上。

我们先把账算清楚：诸如 CVE-2025-62506（服务账户绕过）、CVE-2025-31489、CVE-2025-27414 在上游 2025-10-15 基线中已经修复；而以下 7 个 CVE 是在 2025-10-15 之后才披露、上游拒绝为开源版提供补丁、由 SILO 独立修复并验证的真实漏洞：

18 项 SN-2026-* 安全边界加固

除了公开披露的 CVE，我们在对抗性代码审查与真实多节点验收中，还系统性地挖掘并修复了 18 项安全边界缺陷（完整索引见安全公告总表）：

1. SigV4 签名头完整性与策略条件键隔离（SN-2026-011、SN-2026-003）：
   • 上游允许攻击者在已签名的 SigV4 请求外附加未签名的 X-Amz-* 业务头（如篡改保留期绕过、对象标签或校验和）。SILO 强制要求请求中出现的全部 X-Amz-* 业务头必须包含在 SignedHeaders 中。
   • 上游在构造 IAM 策略评估参数时，会把客户端请求头和查询参数混入条件字典，导致客户端能伪造 s3:prefix、s3:versionid、s3:ExistingObjectTag/* 或 aws:PrincipalType 等服务端权威条件键。SILO 在 silo-pkg 中将服务端权威条件键与客户端输入彻底隔离，并在 DeleteObjects 与 GetObject 中将 s3:VersionId 严格绑定到实际操作的目标版本。
2. 桶级写权限收紧、指定版本删除授权与管理动作拆分（SN-2026-004、SN-2026-005、SN-2026-009 与 010、SN-2026-017）：
   • 收紧 12 项桶级写操作（如 s3:CreateBucket、s3:DeleteBucket、s3:PutBucketPolicy、s3:PutLifecycleConfiguration 等）的资源匹配规则，拒绝仅授予 arn:aws:s3:::bucket/*（对象通配符）或裸 arn:aws:s3::: 的策略越权修改桶级配置。
   • 显式指定版本 ID（包括 null）进行永久删除时，要求 s3:DeleteObjectVersion；不指定版本、只创建删除标记时仍使用 s3:DeleteObject，批量删除逐项检查。
   • 将启停用户的权限从 admin:CreateUser 中拆出为独立的 admin:EnableUser / admin:DisableUser；将用户自改密码拆分为独立的 admin:ChangeMyPassword（详见密码权限迁移）；修复 IAM 管理接口创建、查看、列举访问密钥时的父账户归属校验。
3. 服务账户授权上限与 Object Lock 治理绕过校验（SN-2026-015 与 016）：
   • 修复内联会话策略（session policy）在没有同名 Allow 语句时丢失父身份 Deny 规则的漏洞，并在临时 STS 凭据与服务账户每次鉴权时实时复核父账户当前权限上限。
   • 修复 PutObject 覆盖受 GOVERNANCE 模式保护的对象时未要求 x-amz-bypass-governance-retention: true 请求头的漏洞；在 PutObjectRetention 放行治理模式绕过前先完成 XML 请求体合法性校验。
4. IAM 持久化撤销、策略重载锁隔离与 LDAP 长 DN（SN-2026-013）：
   • 在多节点与多站点复制下，过去删除用户、策略或服务账户后，迟到的站点复制事件或漏掉的对端通知会让已删除的身份和旧权限“死而复生”。SILO 引入持久化修订号、删除墓碑与父身份撤销截止线（siloParentRevocation），并在收到对端删除通知时强制重载已提交的持久状态，彻底封堵旧事件重放恢复权限的路径。
   • 将慢速的 IAM 策略加载与 KMS 解密移出全局内存鉴权缓存锁，贯通 KMS 请求取消信号（设计记录）；修复 LDAP StartTLS 优先级与超长 DN 转义导致的 255 字节文件名越界问题（设计记录）。

3. S3 协议补齐与端到端校验和

在 S3 协议层，SILO 这一年重点解决了三件事：把上游留下的空壳 API 补齐、把多池条件读写语义拉齐、把分片与加密场景下的校验和及逻辑大小算准。

4. 跨站复制与生命周期

在开启了跨站复制（Bucket / Site Replication）或远端分层（ILM Tiering）的生产集群中，最危险的缺陷往往不是“请求直接报错”，而是源端与备端静默不一致，或者生命周期规则误删了仍在引用的底层数据。过去一年里，SILO 围绕复制与生命周期修复了六类核心问题：

此外，在复制重同步（Resync）与站点桶配置同步上，SILO 为每个 Resync 任务与目标端拆分了独立的取消上下文并修正了 ReplicatedCount/FailedCount 统计（复制重同步正确性），同时为桶级元数据（CORS、生命周期、加密、复制、锁配置）重载加装了逐桶互斥锁与可选的字段级删除墓碑（桶配置收敛）。

5. 存储写入、回滚与多池一致性

在纠删码存储引擎中，正常路径很容易写对，真正的坑全在慢盘、部分写失败回滚、并发覆盖写与多存储池（Multi-Pool）扩缩容的交叉地带。20261026 正式版收敛并交付了以下三组底层存储保护：

1. 存储提交错误分类与覆盖回滚 RPC 透传

• 暂存 xl.meta 缺失归类为 503 SlowDownWrite：在提交阶段，若个别慢盘因并发清理或时序竞争导致 .minio.sys/tmp 中的暂存 xl.meta 缺失，SILO 将其归类为 errFileNotFound 并向客户端返回 HTTP 503 SlowDownWrite 触发安全重试，而不是像过去那样误报 404 ObjectNotFound（错误分类设计记录）。
• 覆盖写回滚选项透传与超时边界：转发存储 RPC 的删除选项（包括覆盖写回滚所需的旧数据目录），同时保持既有的磁盘/RPC 超时、请求取消、对象锁、读仲裁与自愈规则。需要明确的是：客户端收到请求超时并不代表底层磁盘或 RPC I/O 已经停止，也不代表写入一定未提交——在部分磁盘故障、租约丢失或网络分区下，迟到提交或延迟 UndoWrite 仍可能发生（10 月维护候选中曾尝试的已接纳 I/O 排空等待与逐盘变更锁已在 dcc2f20ba 中撤回，详见最终维护边界）。

2. 多池并发锁、两阶段批量删除与跨池迁移保护

在多存储池（Multi-Pool）集群中：

• 跨池共享对象锁：修复了多池集群中不同存储池各自维护局部锁导致并发写入、删除与元数据更新互不感知的问题。
• 多池批量删除保住最新副本（#257）：过去多池 DeleteObjects 对所有存储池并行下发删除，一旦保存最新版本的池删除成功、而保存旧副本的池因磁盘故障删除失败，旧池里的过期数据就会“复活”成当前可见对象。SILO 将多池删除改为两阶段执行：先定位每个对象的权威版本所在池，优先清理非权威池中的旧副本，待旧副本清理确认后再删除权威池副本，并在部分失败时保护仍被引用的远端分层对象（多池删除设计记录）。
• Rebalance 与 Decommission 迁移保护：修复了跨池再平衡（Rebalance）与池退役（Decommission）过程中丢失对象标签、覆盖目标池更新版本或漏处理删除标记的问题（多池对象一致性）。

3. 盘间分歧下的 LIST 恢复（#239）

在滚动重启叠加并发覆盖写时，部分磁盘排在前面的少数派新状态或未决条目可能导致 ListObjects 漏掉实际上可读的对象。SILO 在保持无锁快路径的前提下，对盘间出现分歧的候选条目执行按需确认，严格区分“对象已删除”与“磁盘读取故障”，并将终端错误正确传递到分页响应中（LIST 恢复设计记录）。

6. 完整管理面回归：SILO Console v2.5.1 与 mcli 20261026

对日常运维人员来说，SILO 与上游 MinIO 最直观的差异体现在管理控制台（Console）和命令行客户端（mcli）上。

SILO Console v2.5.1：从被阉割的浏览器回到完整管理台

2025 年中，上游将社区版 MinIO 内嵌的 Console 裁剪到了 v1.7.7，砍掉了所有集群管理、IAM、策略、生命周期、复制、诊断与监控界面，只留下一层简陋的对象浏览器；随后更是直接删除了 github.com/minio/console 仓库。

SILO 在社区开发者 Georg Mangold（@gmangold）恢复的历史分支基础上，从 v2.0.0 持续迭代至 v2.5.1，交出了一份不仅恢复全功能、而且比原版更轻量可靠的管理控制台：

Console 2.5.1 进一步修复切换组状态时丢失成员、OIDC 组权限、TLS 代理会话 Cookie、凭据导出及键盘焦点问题，完整变化见 Console 2.5 系列发布说明。

mcli 20261026：说真话的退出码与只读校验和核验

在客户端侧，pgsty/mc 以 mcli 作为二进制与包名称发布（同时保留 MC_* 环境变量与配置格式兼容），重点解决了自动化脚本最头疼的“表面成功、实际失败”问题：

• 新增只读 mcli checksum verify 命令：无需下载落盘或修改对象，直接对存储桶、前缀或指定对象版本执行端到端 FULL_OBJECT 校验和核验，支持 --versions、--Algo 与 --json 输出。
• 修复一系列静默返回 0 的错误退出码：
  • mcli admin info --json 在权限被拒绝或节点报错时输出 status: error 的同时返回非零退出码（上游仍以 0 退出）；
  • mcli mirror、mcli mv、mcli retention、mcli legalhold、mcli sql 在遇到部分对象失败、源删除失败或权限拒绝时，均确保返回非零退出码；
  • 下载流中途断开时直接报错返回，绝不把截短文件当作成功下载。
• 安全的 mirror 删除传播与服务重启预演：修复 mirror --remove 在源端列举异常时的误删风险；为 mcli admin service restart 增加 --dry-run 预演模式；支持在别名配置中持久化可选的 region 字段。

20261026 还加入客户端身份缓存隔离、复制重同步 JSON 终态输出和速率溢出修复、start/cancel 部分失败的非零退出码，以及缺少实时指标时的 batch pending 状态与有界回退。完整命令与脚本迁移说明见 mcli 更新。

7. 运维配置、供应链与二进制分发

在服务端运维配置与交付链路上，SILO 做了四类贴近生产环境的改造：

1. 让请求头超时真正生效，并补齐可信代理边界：
   • 上游虽然定义了 --read-header-timeout / MINIO_READ_HEADER_TIMEOUT，但并未真正传给底层 http.Server，导致 HTTP/1 连接在慢速滴灌请求头（Slowloris）下可以无限期挂住。SILO 将该参数真正接入 HTTP 服务（默认 30 秒绝对读取期限，设计记录）。
   • 新增 MINIO_API_TRUSTED_PROXIES 与 MINIO_IDENTITY_LDAP_STS_TRUSTED_PROXIES，默认不再盲目信任客户端伪造的 X-Forwarded-For；新增 CONSOLE_WS_MAX_MESSAGE_BYTES 与 CONSOLE_WS_MAX_DECOMPRESSED_BYTES 限制内嵌控制台 WebSocket 帧大小。
   • 新增原生 silo healthcheck 子命令，使无 shell 的 distroless 容器也能直接执行就绪与存活探针；收紧 MINIO_CONFIG_ENV_FILE 解析器，拒绝畸形配置行。
2. 修复事件通知目标（Notification Targets）连接管理：
   • 修复 NATS 断线重连与 JetStream 异步发布回复主题冲突、AMQP 确认锁竞争、PostgreSQL/MySQL TLS 配置加载，并显式保留 Kafka 通知目标的默认协议版本 2.1。
3. 彻底移除自更新与后台外联（Call-Home）：
   • 永久移除二进制原地自更新（MINIO_UPDATE）以及全部 SUBNET 注册、遥测、许可证检查与后台外联代码。软件升级完全交还给操作系统的包管理器（RPM/DEB/APK）与容器编排系统。
4. 重建可验证的多架构发行供应链：
   • 全栈升至 Go 1.27.3（内置 crypto/x509 失信中间证书拦截），容器基础镜像采用 UBI 9.8 与 distroless 双变体，内置静态编译的 curl 8.23.0 并应用 Red Hat RHSB-2026-012 根证书封禁列表。
   • 每个正式版本均提供 Linux（amd64/arm64/ppc64le/s390x）、macOS（amd64/arm64）、Windows（amd64/arm64 ZIP 归档）二进制、RPM/DEB/APK 软件包、Docker Hub 多架构镜像（pgsty/silo、pgsty/silo-console、pgsty/mc、pgsty/kes），并附带 GPG 签名、SPDX SBOM 与 GitHub Sigstore 构建证明（详见下载与安装）。

8. 诚实的边界：撤回的尝试与尚未解决的问题

维护一个生产级存储系统，不仅要看合并了什么，更要看试过之后因为代价过高而主动撤回了什么。这一年里，有四项改动我们在做完实现、跑完压测或故障注入后，最终决定撤回或关闭：

1. 撤回公开持久化的 ListMultipartUploads 磁盘扫描（#79）：
   • 初衷：上游的 ListMultipartUploads 只查单节点内存缓存，节点重启后未完成的分段上传在列表中就会消失。我们曾在 9 月版本中尝试扫描底层存储池/纠删集上的持久化上传目录。
   • 撤回原因：容量实测表明，持久扫描的延迟随前缀深度与残留未完成上传数量呈线性恶化，在 20,000 个未完成上传规模下会直接触发请求超时并拖慢磁盘 I/O。因此在 Server 20261018 中，我们果断撤回了公开持久扫描并退役了可选 strict 模式，恢复为节点本地缓存加精确 key 查询（详见 ListMultipartUploads 设计与容量证据）。
2. 撤回默认路径上的严格代际拒读与自动跨池读恢复：
   • 初衷：当部分覆盖写失败导致不同磁盘或不同存储池之间出现版本代际分裂（split generation）时，曾尝试在读取路径上直接拒绝存在代际分歧的读取，或在 GET 时自动跨池恢复。
   • 撤回原因：故障注入表明，在部分覆盖写失败后直接拒读会破坏 MinIO 原有的可用性契约（即部分覆盖失败后旧版本仍应可读）。因此我们将严格拒读诊断降级放入非默认的 consistency_strict 构建标签中，默认生产构建继续保留原有的读取仲裁与自愈行为。
3. 放弃多池覆盖亲和性方案（#245）：
   • 初衷：在多存储池集群中，同名对象的无版本覆盖写可能落到新池，从而在旧池留下过期副本。#245 尝试把覆盖写强制路由回对象原先所在的存储池。
   • 放弃原因：当历史存储池因为坏盘失去写仲裁、而集群中其他健康存储池仍有充足空间时，强制亲和会让覆盖写直接失败；且两轮 m3 多节点压测显示小对象覆盖延迟仍未达标。最终我们选择关闭 #245 不予合并（详见多池覆盖亲和设计记录）。
4. 移除实验性的访问频率池间分层（ilm access_*）：
   • 该实验特性从未达到生产可靠性标准，已在 Server 20260916 中彻底清理（详见访问频率分层移除说明）。

当前仍需注意的工程与升级边界

最后，把当前版本的客观边界再次汇总如下，供评估与升级时参考：

• 没有分布式锁 fencing：当节点因 GC 停顿、网络抖动或慢盘导致锁租约过期后，失去租约的节点上已经在途的提交仍可能晚于新写入落地；部分元数据更新在故障窗口下仍可能短暂暴露旧标签或旧属性。本版保持既有超时语义，不能把请求返回当作底层 I/O 已结束的证明。
• 不宣称未经对等验证的全集群吞吐百分比：我们在单点热路径上有明确的微基准（例如 silo-pkg v3.14.3 将 ContainsAdminAction 从每次调用分配 24 次内存、742.5 ns/op 优化为零分配、5.53 ns/op），但尚未在固定硬件上对 2025-10-15 与 2026-10-26 运行完整的端到端多节点吞吐基准。
• 协调升级要求：虽然底层磁盘格式保持 xl.meta v1.3 兼容，但启用持久化 IAM 撤销（siloParentRevocation）、站点复制元数据墓碑时，集群中的所有参与节点应协调升级至相同版本，不支持新旧节点长期混跑或滚动降级（详见组件版本矩阵与 IAM 升级指南）。
• 已知待修细节：当前仓库内 Helm Chart（7.0.3）的默认服务端镜像标签仍停留在 RELEASE.2026-09-16T00-00-00Z（部署新版本时需通过 values.yaml 显式指定目标标签）。

结语

一年前按下 fork 按钮时，我们的目标很朴素：不造噱头、不画大饼，让还在跑开源 MinIO 的生产环境有安全补丁可打、有完整控制台可用、有干净的二进制包和镜像可拉。

一年下来，604 次提交、7 个 CVE 补丁、18 项安全边界加固、几十篇公开在设计归档与安全归档里的根因分析与取舍记录，就是 SILO 交出的第一年答卷。

如果你正在使用开源版 MinIO，可以直接查阅迁移指南与下载页面；如果你在生产环境中遇到任何可复现的协议、复制或存储问题，欢迎直接到 pgsty/silo 提 Issue。

路还长，我们继续维护。