PGSTY SILO 博客

• 1: 文章
  • 1.1: SILO 一年回顾：相比上游 MinIO，我们到底干了什么？
  • 1.2: 续命 MinIO：承诺兑现
  • 1.3: MinIO 已死，MinIO 复生
  • 1.4: MinIO已死，谁能接盘？
  • 1.5: MinIO已死
• 2: 发布注记
  • 2.1: SILO 20261026：Server、mcli 与 KES 联合发布
  • 2.2: SILO 20261018 发布说明
  • 2.3: silo-pkg 3.14.3 发布
  • 2.4: PGSTY KES 20261018 发布
  • 2.5: SILO Console 2.4.2 发布
  • 2.6: mcli 20261018 发布
  • 2.7: silo-pkg 3.14.2 发布
  • 2.8: SILO 20261015：已替代草稿记录
  • 2.9: SILO Console 2.4.1 发布
  • 2.10: silo-pkg 3.14.1 发布
  • 2.11: SILO 20260916 发布注记
  • 2.12: mcli 20260916 发布
  • 2.13: mcli 20260913 发布
  • 2.14: silo-pkg 3.14.0 发布
  • 2.15: SILO Console 2.4.0 发布
  • 2.16: Silo Console 2.2.0 发布说明
  • 2.17: SILO Console 2.5：界面与管理功能更新
  • 2.18: silo-pkg 3.15：Go 1.27.3 与 S3 SDK 修复
  • 2.19: Silo Console 2.1.0 发布
  • 2.20: Silo Console 2.0.0 发布
  • 2.21: silo-pkg 3.13.0 正式发布
  • 2.22: silo-pkg 3.12.0 正式发布
  • 2.23: Silo Pkg 3.11.0 发布
  • 2.24: Silo 20260903 正式发布
  • 2.25: 显式版本删除现在要求 DeleteObjectVersion
  • 2.26: mcli 20260903 正式发布
  • 2.27: mcli 20260806 发布
  • 2.28: Silo 20260806 发布
  • 2.29: Silo 20260804 发布
  • 2.30: mcli 20260804 发布
  • 2.31: Silo 20260618 发布
  • 2.32: Silo 20260417 发布
  • 2.33: Silo 20260325 发布
  • 2.34: Silo 20260321 发布
  • 2.35: Silo 20260314 发布
  • 2.36: Silo 20260214 发布
  • 2.37: Silo 20251203 发布
• 3: SILO 安全编年史
  • 3.1: 十月安全更新：Object Lock、管理凭据与 JWK 解析
  • 3.2: SN-2026-015 与 SN-2026-016：S3 Object Lock 治理模式保留锁绕过与指定版本号原地覆盖漏洞分析
  • 3.3: 九月安全修复：载荷完整性、IAM 撤销与 Console 分享
  • 3.4: SN-2026-011：修复与发布状态
  • 3.5: CVE-2025-62506：Session Policy 权限提升
  • 3.6: SILO 20260903 安全说明：SN-2026-006 至 010
  • 3.7: CVE-2026-32285：最终无需补丁的 jsonparser 通告
  • 3.8: CVE-2026-33322：OIDC JWT 算法混淆
  • 3.9: CVE-2026-33419：LDAP STS 用户枚举与限流链演进
  • 3.10: CVE-2026-34204：复制元数据注入
  • 3.11: CVE-2026-39414：S3 Select 超大记录与 SIMD 快路径绕过
  • 3.12: CVE-2026-40344：Snowball 自动解包认证绕过
  • 3.13: CVE-2026-41145：Unsigned-Trailer 查询认证绕过
  • 3.14: CVE-2026-42600：ReadMultiple Storage-REST 路径穿越
  • 3.15: SN-2026-002：内部节点路径包含审计——补完 CVE-2026-42600 欠下的那笔账
  • 3.16: SN-2026-003：s3:versionid 条件求值缺陷与请求条件隔离加固
  • 3.17: SN-2026-004：对象级策略授权越界命中桶级变更操作
  • 3.18: SN-2026-018：客户端源地址信任边界、转发头欺骗与 aws:SourceIp 加固
  • 3.19: SN-2026-019：通知子系统配置键注册缺失与校验报错脱敏
  • 3.20: CompleteMultipartUpload 重复分片号漏洞分析与修复
• 4: 设计归档
  • 4.1: SILO、KES 与 OpenBao：密钥归属和恢复
  • 4.2: 写死 TLS 参数与握手兼容性
  • 4.3: 桶配置复制：来源时间、删除与确定性收敛
  • 4.4: SigV4 签名头覆盖边界：拒绝未签名的 x-amz-* 请求头
  • 4.5: Object Lock 复制排序
  • 4.6: SSE-C 副本完整性
  • 4.7: 持久化 IAM 撤销
  • 4.8: 多池对象一致性
  • 4.9: 联邦 CopyObject：保持目标对象契约
  • 4.10: 复制可靠性：删除完成、MRF 可见性与 resync 取消
  • 4.11: FULL_OBJECT 校验和复制：在初始化上传时保留类型
  • 4.12: IAM 策略重载：锁粒度、请求取消与超时预算隔离
  • 4.13: LDAP 长 DN：恢复登录可用性并守住 IAM 撤销安全边界
  • 4.14: 复制标签排序：修订时间戳、墓碑与复活
  • 4.15: SILO Server 20260903 发布前复审
  • 4.16: 多池覆盖亲和：为何最终没有采纳 #245
  • 4.17: 副本元数据归一化：可信复制不得重新注入什么
  • 4.18: 请求头截止时间：绝对头部上限与滚动的正文空闲超时
  • 4.19: 条件 DELETE：一个条件对应一个逻辑对象
  • 4.20: 只预览文本，绝不执行：SILO Console 文本预览设计
  • 4.21: 数据库通知统一连接串：#53 的兼容性边界
  • 4.22: 多池删除：失败时保住最新副本
  • 4.23: Go 1.27 TLS 默认值与 OIDC Discovery 故障诊断
  • 4.24: 鉴权前不做 I/O，Header 不授予权限
  • 4.25: 一个端点，两种权限：彻底分离用户与组状态
  • 4.26: IAM Admin API 授权边界修复
  • 4.27: 配置环境文件不是 Shell 脚本
  • 4.28: 两把 SSE-C 密钥，一份 CopyObject 响应
  • 4.29: ListMultipartUploads 行为契约与设计权衡
  • 4.30: 为什么 CompleteMultipartUpload 必须返回 ChecksumType：PR #57 评审记录
  • 4.31: 总量未知时，进度条应该说什么
  • 4.32: 列举不能丢掉仍有仲裁的 null 版本
  • 4.33: ListObjects 快捷路径不能把不存在的桶伪装成空桶
  • 4.34: 只读 Checksum 审计与可靠的 CLI 输出契约
  • 4.35: 可选校验和，强制失败：修复 UploadPart 与 UploadPartCopy 兼容性
  • 4.36: BadDigest、InvalidRequest 与 CompleteMultipartUpload 校验和契约
  • 4.37: 旧版元数据与扫描响应复用时的残留字段修复
  • 4.38: LIST 漏项修复：仅对存疑对象补读确认并收敛锁等待开销
  • 4.39: 对象锁保留期越权与版本覆写漏洞修复设计（SN-2026-015 / SN-2026-016）

1 - 文章

关于 MinIO、S3 兼容对象存储与 SILO 社区分支的文章与分析。

1.1 - 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。

路还长，我们继续维护。

1.2 - 续命 MinIO：承诺兑现

两个月前，我在《MinIO 已死，MinIO 复生》里立了一个 flag，承接上游的烂摊子，跟 CVE、修 Bug。 那篇文章上了几个小时的 Hacker News 头条。鼓励不少，质疑也不少：一个人，真维护得了这种项目吗？

这个问题其实问得很好。因为真正见真章的时刻，不是点 fork 按钮，也不是改 README 文档，而是当安全漏洞真砸下来的时候。

现在，这件事可以交账了。

4 月 15 日到 17 日，三天时间，pgsty/minio 发布了 RELEASE.2026-04-17，连续修掉并关闭了 4 条 CVE 加几条同期披露的安全漏洞，OIDC JWT 算法混淆（CVSS 9.8）、LDAP 登录用户名枚举与暴力破解、复制头元数据注入导致对象不可读、S3 Select 超大记录打穿内存，以及两条 unsigned-trailer 写入路径上的签名绕过。

A promise made, a promise kept.

当时我把话说得很清楚：不做新特性，只保障供应链；遇到可复现问题和安全漏洞，会积极跟进和修补。这件事，现在算是交账了。

上游发生了什么

2025 年 12 月，MinIO 把开源仓库改成 维护模式。README 里写着 “安全修复会逐例评估”。 到 2026 年 2 月，仓库直接归档，首页变成了 “当前仓库已经不再维护”。但同一个仓库的 SECURITY.md 还留着：“我们总会为最新版本提供安全更新”。

而最近一个月，MinIO 又暴漏出四个高危漏洞，两个中危，覆盖最后的开源版本。

与此同时，上游官方仓库距离最后一次发布已经过去 184 天。 他们披露漏洞，但只在商业版本中修复。对于开源版用户，他们给的建议就一条，“升级到商业版 AIStor”。

顺便一提，MinIO 入门起步价约 10 万美元/年，400 TiB，单价基本跟 AWS S3 差不多，简直离大谱，毕竟这是纯软件。

一种很精致的玩法。仓库归档了，道义责任撇清了；但 CVE 通告照发，既能刷一波 “我们很负责任” 的存在感，又恰好能把用户赶进商业版的羊圈。

挺聪明的。只是还得有人得把这坑填上。

这次修了什么

这篇文章我不想写成漏洞分析报告。具体每一条的 CVSS 分数、攻击链、PoC 代码，我在 发布注记 里都一一列了，感兴趣的朋友可以去看。这里只说一句话版本：

• CVE-2026-33322（OIDC JWT 算法混淆，CVSS 9.8）：在特定 IdP 配置下可以 伪造任意身份，包括 consoleAdmin。攻击者只要知道 OIDC ClientSecret，数学上就能签出一张 “我是管理员” 的通行证，MinIO 会乖乖验证通过。影响范围从 2022 年 11 月到今年 3 月，三年半。
• CVE-2026-33419（LDAP STS 登录枚举与暴力破解）：攻击者可以先用登录接口枚举出真实用户名，再无速率限制地爆破密码，最后直接拿到 STS 凭证。整个链条从头到尾没有一道闸。
• CVE-2026-34204（复制头元数据注入）：普通 PUT / COPY 请求里夹一些 X-Minio-Replication-* 头，就能把对象写成 永久不可读 状态，数据还在，但你再也读不出来。
• CVE-2026-39414（S3 Select 内存耗尽）：一条恶意请求，就可以把 MinIO 进程吃到 OOM。
• GHSA-hv4r-mvr4-25vw / GHSA-9c4q-hq6p-c237：unsigned-trailer 路径上的两条签名校验绕过，匿名或伪造签名的请求可以在某些路径下成功写入对象。

再加上 go-jose、go.opentelemetry.io 和 Go 1.26.2 自身吸收的一连串标准库与依赖 CVE，这一版本聚合了接近二十条安全条目。

有的能伪造身份拿到高权限访问，有的能把登录入口拿去枚举和爆破，有的能把对象写成永久不可读，有的能用一条请求把服务吃到 OOM，还有的能在缺失签名校验时直接写入对象。这不是小修小补，这是实打实的维护责任。

这次是怎么修的

在之前那篇文章里，我明确说过我会用 AI Coding Agent 来维护这个项目，事实上我也是这么做的。这一轮修复里，我扮演了一个 Blind Manager 的角色。

简单解释一下我的工作范式。具体到每一条漏洞，流程大致是：

1. Codex 先打铁：根据 CVE 描述和相关代码路径，产出第一版补丁。
2. Claude Code 做 review：站在对抗视角挑毛病。
3. 回到 Codex：我要求它，如果你同意 Claude Code 的意见，那就返工；如果不同意，那就反驳，把理由写清楚。
4. 把所有思路摊开，再交给 Claude Code 做一轮 review。必要时来回再跑几轮，直到两边收敛。
5. 进行测试：依然是类似的对抗操作，由 Codex 设计测试用例，Claude 补充。然后由 Codex 去实际执行并产出结果，再由 Claude Code review。
6. 我来定夺：看 diff，跑测试，做最后决策与验收。

这个过程中，我自己不写一行代码。我的工作是定义问题、约束边界、挑方案、看 diff、跑验收、拍板。

公开提交页上，你能直接看到 Vonng、Codex、Claude Code 三个名字同时出现在几条关键安全提交的 Co-authored-by 里。这不是作秀。这就是 2026 年一个人维护一个中型基础设施项目的真实样子。

这种协作模式有几个实际的好处。

第一，两个 agent 对抗能筛掉大部分“听起来都对、实际上不对”的方案。 单独一个 agent 在修复安全漏洞时会有一种 “幻觉级自信”，写出一份解释流畅、看起来干净的补丁，但漏掉了一个边界条件。让另一个 agent 从敌对视角审视它，这种方案很难活过第一轮。

第二，逼出显式的权衡。 两家不同实现路径撞上了，自然就要回答 “为什么你选 A 而我选 B”。这个对话本身就是在把隐性假设显性化，而显性化的假设，才是我作为 Blind Manager 能拍板的东西。

第三，真正的维护是“补丁打补丁”，而不是一把梭。 拿 LDAP STS 这条洞来说，首版修复推出来以后，很快发现成功请求不该消耗限流额度、默认不该信任 X-Forwarded-For、限流账户要按 “源 IP + 归一化用户名” 双维度算账。 然后又连着补了三次提交才算收敛干净。这个过程如果没有 agent 的火力支持，单个 maintainer 要一边读代码一边迭代，成本是完全不一样的。

有些事还是要人来拍板

但也正因为这个模式运转得不错，maintainer 唯一的不可替代性，就凸显在那些 AI 给不出最后答案的地方。

最典型的就是 OIDC 那条 fix。表面上，它是一个 JWT 算法混淆漏洞；但实质上，它是一个 兼容性和安全性之间的取舍。

简单解释一下。JWT 的签名算法分两类：非对称（RS256、ES256 这类，签名用私钥、验签用公钥）和 对称（HS256 这类，签名和验签用的是同一个密钥）。OIDC 的标准姿势是 IdP 用自己的私钥签 token、MinIO 用公开的 JWKS 拿到公钥来验签。公钥是公开的，攻击者拿不到私钥，所以没法伪造。

而 HS256 这类对称算法的问题在于：签名和验签用的是同一个密钥。这个密钥就是 MinIO 自己也存着的 ClientSecret。于是攻击者只要拿到这个 “共享秘密”，就既能当裁判又能当运动员。自己用它签一张 token，MinIO 拿自己存的同一个密钥一验，当然通过。

这在教科书上是 JWT 的经典反模式，但历史代码就是这么走过来的。修法有几条路可选：

• 继续容忍这条历史路径，只在某些条件下收窄：保留向后兼容，但安全边界依旧模糊。
• 严格 JWKS-only，拒绝 HS256 等对称签名 token：一刀切、安全边界清晰，但少数本来就配得模糊的用户会感到配置失效。

两个 agent 可以给我列出每个方案的 trade-off，可以写好任何一个方案对应的补丁，但它们不会替我决定。最后我的选择是后者，恢复严格的 JWKS-only 验证路径，明确拒绝不该接受的 HS256。

这个决定也许会让少数模糊配置失效，但安全边界终于清楚了。AI 可以提三个方案，真正承担后果的人还是 maintainer。

这就是 Blind Manager 模式的上限，也是下限：机器负责穷尽方案，人负责选择方向。

不是情怀，是必需

我一直说，这个 fork 不是情怀，也不是 cosplay。它存在，首先是因为这是我自己要用的东西。

MinIO 是 Pigsty 的生产依赖。我需要可用的二进制、完整的控制台、持续可得的包，以及真正有人处理的 CVE 补丁。也正因为我自己在用，所以这条线没有太多空话空间：它不是拿来讲故事的，而是拿来顶生产环境的。

这也决定了我的策略很保守。不会去追求 “新特性很酷”，也不会把仓库弄成另一个方向的实验场。我的目标一直都很明确：保持兼容，守住供应链，在该修的时候把问题修掉。

到现在，这个分支在 GitHub 已经有了 1300 star，在 Docker Hub 也累计了 五万+ 下载。数字本身不算什么惊人的成就，但它至少说明了一件事：需要这条线的人，并不只有我自己。

2026-10-25 更新： 当前维护的 Docker 镜像已更名为 pgsty/silo。下文 Docker 示例已更新为当前名称，详见迁移指南。

对已经在用 MinIO 开源版的人来说，迁移到这个分支的成本其实很低：

• Docker 镜像：把 minio/minio 换成 pgsty/silo，一行的事。
• RPM / DEB：GitHub Release 里都有，或者用 pig 一键装。
• 源代码仓库：pgsty/minio
• 中文文档：silo.pgsty.com/zh/
• 英文文档：silo.pgsty.com

你不需要换掉整个系统，也不需要重新学习一套对象存储；多数情况下，只是把一个失去维护的上游，替换成一个还会继续交付补丁的分支。 如果你需要完整的生产级部署方案，Pigsty 里也提供了开源免费、开箱即用的 MinIO 生产级高可用部署支持。

承诺是什么

两个月前那篇文章发出去以后，有人私信我，说这事看着挺悲壮。其实不是。

写那篇文章的时候我没有赌气，发这个版本的时候我也没有激动。从头到尾，这就是一件普通得不能再普通的事，用的东西坏了，自己修一下。仅此而已。

只是到了 2026 年，“自己修一下” 这件事的门槛，被 AI Coding Agent 重新定义了。一个人，加两个 agent，加一点点判断力，足以把一个六万 star 的中型基础设施顶起来。这不是我厉害，这是 时代变了。

以前我们谈论开源的韧性，谈的是 “社区”，几十上百个志愿者众筹时间。现在这套剧本还在，但 底下多了一层保险：哪怕社区散了，只要有一个人还愿意按下 fork 按钮，项目就能续命。

承诺是什么？承诺不是 “我有激情”，也不是 “我有道义”。承诺是 “下一个 CVE 出来的时候，我还在”。

下一个 CVE 出来的时候，老冯还在。

就这样。

1.3 - MinIO 已死，MinIO 复生

MinIO 开源仓库正式归档，不再维护。一个时代落幕，但开源的精神不死。 老冯 Fork 了 MinIO，复活了管理控制台，重建了二进制分发渠道，让 MinIO 浴火重生。

2026-10-25 更新： 当前维护的 Docker 镜像已更名为 pgsty/silo。下文 Docker 链接与示例已更新为当前名称，详见迁移指南。

如果你正在用 MinIO，把 minio/minio 换成 pgsty/silo ，其他一切照旧。

MinIO 的死亡证明

2025年12月3日，MinIO 在 GitHub 上宣布进入"维护模式"。我写了一篇《MinIO 已死》。

2026年2月12日，MinIO 在 GitHub 首页将状态从"维护模式"更新为 “不再维护”，随后正式将仓库归档（Archived）。Read-only，不接受 PR Issue，不接受任何贡献。 一个拥有六万 star、超过十亿次 Docker 拉取的项目，变成了一座数字墓碑。

如果说12月是 临床死亡，那 2月的这个提交就是 正式开具了死亡证明。

今天（2月14日），一篇题为《How MinIO went from open source darling to cautionary tale》的长文引发了广泛传播，详细复盘了 MinIO 从开源宠儿到反面教材的完整堕落时间线。

Percona 创始人 Peter Zaitsev 也在 LinkedIn 上表达了对开源基础设施可持续性的忧虑。国际社区的共识已经形成：MinIO 完了。

不是 “不更新了” —— 是 彻底的、不可逆的、官方盖棺定论的死了。

回顾这18个月的时间线，你会发现这不是一次意外死亡，而是一场蓄意的、分阶段的自毁：

一家融了1.26亿美元、估值十亿美金的公司，花了五年时间，亲手把自己建立的开源生态一砖一瓦地拆干净。

这比跑路还让人难受 —— 因为跑路至少是一次性的，MinIO 选择了凌迟。

但开源不死

故事到这里，按照正常剧本应该是一声叹息，然后大家各回各家。

但我想讲一个不一样的故事 —— 不是悼词，是复活。

MinIO 公司可以归档一个仓库，但它归档不了 AGPL 协议赋予社区的权利。

讽刺的是，AGPL 正是 MinIO 自己选的。他们当年从 Apache 2.0 换成 AGPL，是为了在保留开源名份的同时拿它当武器打 Nutanix 和 Weka。 但开源许可证 是双刃剑 —— 同一把刀，如今也 保障了社区 Fork 的完全合法性。 代码一旦以 AGPL 发布，许可就不可撤回。你可以把仓库设为只读，但你收不回已经发出的许可证。

这就是开源协议设计的深意：公司可以抛弃项目，但不能带走代码。

所以 —— MinIO 已死，但 MinIO 也可以复生。

但也先别急着热血沸腾。Fork 谁都会，点一下 Fork 按钮的事。 真正关键的问题不是 “能不能 Fork”，而是 有没有人真的能把它当成生产组件来维护。

我本来并不想接这个摊子 —— 但我在 MinIO 进入维护模式后等了一两周，社区里没有人站出来说 “我来”，我就只能自己上了。

简单介绍一下背景：我一个人维护着整个 Pigsty 项目 —— 一个全功能的 PostgreSQL 发行版，451 个扩展，支持 14 个 Linux 发行版的交叉构建。 我同时维护着 270+ PG 扩展、六七款 PG Fork、几十款 Go 软件（Victoria/Prometheus 等）的全平台构建工作流，还是游刃有余的。

我对 MinIO 也不陌生。2018年，我们在探探内部就维护过一个 MinIO 的内部分支（当时还是 Apache 2.0）， 支撑了约 25 PB 数据，是当时国内最早、最大的 MinIO 部署之一。

更关键的是，MinIO 在 Pigsty 中是 真实使用的组件， 很多用户将它作为 PostgreSQL 的备份仓库默认跑在生产环境里。

这不是一个 “要不要做” 的问题，而是 不做不行。 早在2025年12月 MinIO 宣布维护模式时，我就已经自己动手创建了修复了 CVE 的二进制。

pgsty/minio RELEASE.2025-12-03T12-00-00Z

我们做了什么

截至今天，我们做了三件事。

1. 复活管理控制台

这是社区最愤怒的一刀。

2025年5月，MinIO 把完整的管理控制台（Admin Console）从社区版中移除，只留下了一个残废的对象浏览器。 用户管理、桶策略、权限配置、生命周期管理…… 一夜之间全没了。想要？掏钱买企业版。

我们把它弄回来了。

讽刺的是，这甚至不需要逆向工程。你只需要把 minio/console 子模块的版本号改回去就行了。 也就是说，MinIO 当初做的事情就是 改了一个依赖版本号，把完整控制台换成了残废版。功能都在那，代码都在那，他们只是给你关上了门。

他们拆了门窗，我们给装回去了。

2. 重建二进制分发

2025年10月，MinIO 停止分发预编译的二进制文件和 Docker 镜像，只留源码。“请用 go install 自己编译” —— 这是他们给用户的交代。

对于绝大多数用户来说，开源软件的价值不只是一份源码副本 —— 供应链的稳定性才是命脉。 你需要的是一个可以写进 Dockerfile、放进 Ansible Playbook、塞进 CI/CD Pipeline 的稳定制成品，而不是每次部署前先装个 Go 编译器。

我们重建了完整的分发渠道：

Docker 镜像

pgsty/silo 已上线 Docker Hub，docker pull pgsty/silo 即可使用

RPM / DEB 包

为主流 Linux 发行版构建了与原版规格一致的安装包。

CI/CD Pipeline

GitHub 上全自动化构建流程已经搭建完毕，确保供应链持续稳定。

如果你在用 Docker 镜像，把 minio/minio 简单换成 pgsty/silo 就好了

喜欢原生 Linux 安装的朋友，可以直接从 GitHub Release 页面下载 RPM/DEB 包。 老冯的 pig （PG扩展包管理器）也可以简单的免翻墙安装。你也可以自己配置启用 pigsty-infra APT/DNF 软件仓库来安装。

curl https://repo.pigsty.cc/pig | bash; 
pig repo set; pig install minio

一切照旧。

3. 复活社区版本文档

MinIO 的官方文档同样面临风险 —— 原本的链接已指向它们的商业产品 AIStor。

所以我们基于 minio/docs 进行了 Fork，修复了失效链接，恢复了被删除的控制台文档，部署在：https://silo.pgsty.com/zh/

文档采用与原版相同的 Creative Commons Attribution 4.0 协议，完整保留了所有内容，并持续进行必要的维护更新。

我们的承诺与原则

一些话需要提前说清楚，免得产生误解。

我们不做新特性，只保障供应链

MinIO 作为一个 S3 兼容的对象存储，功能已经足够完善。 它是一个 已经完成的软件，它不需要更多花里胡哨的新特性，它需要的是一个稳定可靠、持续可用的版本。

我们做的核心事情就是：确保你随时可以拿到一个能用的、完整的、带管理界面的 MinIO 二进制制成品。 RPM、DEB、Docker 镜像 —— CI/CD Pipeline 自动构建，与你现有的基础设施无缝对接。 不用担心某天 docker pull 拉不到镜像，不用担心 yum install 找不到包。

前提是 MinIO 别用商标武器来搞我，搞我那我就只能重命名了。

这是真实使用的版本，不是归档备份

可能有人会想：这只是又一个 Fork 备份而已吧？不是。 MinIO 在 Pigsty 中是真实使用的组件，很多用户将它作为备份仓库跑在生产环境里。 我们使用的就是自己构建的版本 —— 如果出了问题，我们会第一时间发现，第一时间修复。 我们自己构建的版本，已经在自己的生产环境中用了三个月。吃自己的狗粮，是最好的质量保证。

我们会修 Bug 并跟进安全更新

如果你在使用中遇到问题，欢迎在 pgsty/minio 提交反馈。 如果是我们构建的版本中可复现的问题，以及安全漏洞（CVE），我们都会积极跟进和修补 —— 但请不要将此视作商业 SLA 承诺 —— 我们尽最大努力，以开源社区的方式运作。

在 AI 编码能力突飞猛进，以及决定不做新特性的前提下，我认为只是修复 BUG/漏洞的工作量是完全可控且可以接受的。

商标问题很难搞，但走一步算一步

商标声明：MinIO® 是 MinIO, Inc. 的注册商标。 本项目（pgsty/minio）为社区独立维护的 AGPL 开源 Fork， 与 MinIO, Inc. 无任何关联、从属或背书关系。 本文中对 “MinIO” 的使用仅用于指代该开源软件项目本身，不暗示任何商业关联。

AGPLv3 虽然允许我们合法 Fork 和分发，但商标法是另一个领域。 虽然我们已经在所有地方明确标注了这是一个独立的社区维护版本， 但 MinIO 公司可能会以商标侵权为由对我们提出异议，要求我们停止使用 “MinIO” 这个名字。

如果 MinIO 方面对商标使用提出异议，我们会配合更名。（大概会叫 silo, stow 之类的） 但在此之前，我们认为在 AGPL Fork 中描述性使用原项目名称是合理的， 毕竟我们也不想把所有的 minio 给重命名了 —— 这对用户没有任何帮助。

AI 改变了游戏规则

可能有人会问：一个人能维护得了吗？

2026 年了，情况和五年前不一样。AI 编码工具正在改变开源维护的经济学。

一个复杂 Go 项目的 bug 定位和修复，在 Claude Code 的辅助下，成本已经降低了不止一个数量级。 以前维护一个复杂基础设施项目需要一个专业团队，现在一个自带 AI 助理的老司机就够了。

你想，马斯克砍到 30 人的工程团队就能维护 X/推特 这种级别的系统。 维护个 MinIO 真没什么大不了的 —— 你只需要有测试验收能力就够了。

老冯行，老冯自己就上了。

Just Fork it!

MinIO 公司可以归档一个 GitHub 仓库，但它归档不了六万颗 Star 背后的需求， 归档不了十亿次 Docker Pull 背后的依赖。这些需求不会消失，它们只会寻找新的出口。

HashiCorp 的 Terraform 被 Fork 成了 OpenTofu，活得好好的。 MinIO 的情况其实更有利 —— AGPL 比 BSL 更友好，社区 Fork 没有任何法律风险。 公司可以抛弃项目，但开源协议的设计就不允许代码死掉。

git clone 是开源世界最强大的魔法。当一个公司决定关门的时候，社区只需要两个字：

Fork it.

参考阅读

• MinIO 已死
• MinIO 已死，谁来接盘
• 从AGPL到Apache：Pigsty 协议变更的思考。

1.4 - MinIO已死，谁能接盘？

前天 MinIO 宣告进入维护模式，老冯写了一篇《MinIO 已死》聊了聊这个话题。 很多朋友也问我，MinIO 既然摆烂躺平了，有谁能接 MinIO 的班？

大方向的话，台面上的替代品无非就那几个：Ceph、RustFS、SeaweedFS、Garage…… 老冯把这些方案都打好了 Linux 上的 RPM/DEB 包，挨个试了一遍。

总结一句话：没有完美替代。

各有各的问题 —— Ceph 功能全但太复杂；SeaweedFS 针对小文件优化但需要独立元数据库；Garage 小巧玲珑但功能简陋；RustFS 兼容 MinIO 但竟然还是 Alpha。

MinIO 替代品速览

MinIO 是 AWS S3 的开源替代，所以从单纯的 对象 CRUD 功能 上来讲，任何兼容 S3 API 的对象存储系统都可以作为 MinIO 的替代品。 但如果考虑到非功能类特性 —— 可靠性，可运维性，复杂度，工具链，生态成熟度，运维 SOP 这些，想要 “平替” 掉 MinIO 确实不容易。

这里我们不聊商业存储，云厂商的对象存储服务，只聊开源项目的话，大体上会有这些选择：

Ceph 可能是企业用户的最佳选择，但学习曲线陡峭，适合有专人运维的团队，不像 MinIO 一个二进制走天下。 很多用户并不需要分布式块存储和分布式文件系统的功能，而且运行还需要额外的 Podmon，不如 MinIO 爽利。

SeaweedFS 质量不错，针对海量小文件场景做优化，O(1) 磁盘寻址，小文件场景性能碾压。 但它需要一个独立的元数据库来存储文件元信息，这就带来了外部依赖。如果你需要一个"通用对象存储"，它不是最佳答案。

Garage 是欧洲 Deuxfleurs 团队的作品，拿过欧盟 NGI 资助，适合自托管爱好者和边缘计算场景。 非常轻量（10MB），但 S3 兼容性太弱，没有版本控制，跨区域复制，IAM 这些，不适合企业场景。

RustFS 是唯一一个瞄准"MinIO 替代"生态位的项目，但成熟度不足 —— 竟然还是 Alpha。

RustFS 是否可以替代 MinIO

在所有号称"MinIO 开源替代"的项目中，老冯本来最看好 RustFS，所以特地花了些时间测试。 我在 Pigsty 中尝试将 MinIO 换成 RustFS，大部分逻辑可以复用，但还是有些区别：

• RustFS 对证书名称有特殊要求
• RustFS 的健康检查接口与 MinIO 有所不同
• RustFS 不支持 mc admin 管理命令，无法配置详细的 IAM 策略。这一点对企业用户而言比较重要。

总的来说，跑起来了，但老冯思考再三，还是把这个分支给放弃掉了。因为把 Alpha 版的软件用在生产环境实在是太不像话了。 我是比较期待 RustFS GA 版本出来之后，再来做一次评测。

RustFS 是否会重蹈 MinIO 覆辙

当然，RustFS 这个项目虽然看上去很有潜力，但也存在一些问题。例如，RustFS 是否会重蹈 MinIO 覆辙？ 特别是，RustFS 在很多雷点上，跟 MinIO 十分相似。

老冯请 AI SOTA 三件套（GPT5-pro, Claude4-Opus, Gemini3-pro）对 RustFS 的风险进行了全面的分析评测。

其中 Gemini 对 RustFS 项目提出来了几项相当严重的指控，老冯又请 Claude 核实了一遍。

RustFS 这些风险信号与当年的 MinIO 几乎一模一样：Apache 2.0 + 版权转让型 CLA + 单一商业公司控制。 考虑到这些因素，老冯对 RustFS 的评级从 “乐观期待”，下调为 “谨慎观望”。

所以，应该怎么做？

老冯的 PostgreSQL 发行版 Pigsty 里面集成了 MinIO 作为对象存储的解决方案。 这完全是一个可选的模块，主要作用是 —— 存储 PostgreSQL 备份，以及在其他业务软件需要对象存储的时候提供一个 —— 比如自建 Supabase 。

考察了现有的生态替代品之后，老冯确实是不想再折腾换 MinIO 的事情了，也许会提供一个用 pgbackrest 自己的备份服务器替代掉 MinIO 的选项。

老冯觉得目前最优的方案，还是继续使用 MinIO 的最新版本，锁定版本，做好网络隔离。 等待半年左右，看看社区生态的发展再做打算。如果那时候 MinIO 有人接手，或者 RustFS GA 可用了，再做调整也不迟。

当然，RustFS 也可以抓住这个机会，抢占 MinIO 的生态位，并真的实现一个更好，更安全，协议更友善的 MinIO 版本。 机会不等人，老冯觉得这个窗口也就几个月时间，错过了就是错过了。

继续使用 MinIO 的注意事项

如果要继续使用 MinIO，有这么几个注意事项。第一是应该用什么版本。 虽然说，MinIO 20250422 版本是最后一个功能完整（带有控制台 GUI）的版本，但老冯还是建议使用最新的版本。

因为从 20250422 到现在（2025-12-08）这段期间，MinIO 有一个比较严重的 CVE 安全漏洞。

CVE-2025-62506: Privilege escalation via session policy bypass (HIGH)

这个漏洞允许低权限用户创建一个新的账户实现权限提升。不过如果是在内网环境中，并且做好网络隔离的话，这个漏洞的风险也是相对可控的。 这个漏洞已经在 MinIO 20251015 版本中修复了，但是 MinIO 很鸡贼的从这个版本开始移除了二进制，只提供源代码。

不过老冯觉得还好，因为 MinIO 是一个 Go 语言项目，编译就一条命令，跨平台编译 goreleaser 一把梭也很简单。 流程我已经跑通了，其实很简单，老冯就直接 Fork 了 MinIO ：然后用 MinIO 自己的打包器做了 2025-12-03 的 RPM/DEB 包，起码不会带病上岗。 把 MinIO 重新从一个 “源码发行版” 恢复成一个二进制发行版：https://github.com/pgsty/minio

不过，安全漏洞和BUG还是得有人来修的，MinIO 自己说还是会看情况修安全漏洞。 老冯觉得，社区里如果有人愿意接手 MinIO 的话，现在还真是一个非常好的机会。 从 20250422 版本作为基础，CherryPick 重要的 Bug 和安全修复的话，然后开始维护一个 MinIO 社区版本。

说到底，MinIO 经过这么长时间的社区打磨，已经是一个相当成熟稳定的对象存储系统了 —— 基本上算是一个 “已完成的软件”。 需要的不是更新跟进S3各种花里胡哨的新功能（S3 Vector/S3 Table），而是扎扎实实的修 Bug 和安全漏洞。

这种维护状态的软件，搞一个 LTS，社区自发维护起来并不难。如果 MinIO 团队不愿意继续维护，老冯觉得社区里会自发涌现出接棒的人选 —— 毕竟现在有很多商业存储硬件公司都在用 MinIO。 比起自己从零瞎搞一个对象存储，接手一个成熟的项目，反而是更省事的选择。

题外话与更新（2026-02-14），MinIO 官方仓库已经彻底归档并不再维护。 我创建了一个 Fork：pgsty/minio / 文档 https://silo.pgsty.com/zh/。 搭建了 CI/CD 提供 RPM/DEB 二进制包与 Docker 镜像，基于最后的上游版本 2025-12-03 构建，恢复了 2025-05 阉割的控制台能力。

1.5 - MinIO已死

2025年12月3日，是个值得在开源软件历史上记一笔的日子。 MinIO 官方在 GitHub 上更新项目状态，宣布 MinIO 开源项目进入“维护模式” 。 这基本上宣告了 MinIO 作为一个开源项目的死亡。

MinIO 这家公司，终于完成了从“屠龙少年”到“恶龙”的华丽转身。

从屠龙勇者到新的恶龙

民主化时代（2014–2019）：对象存储的 Apache

MinIO 成立于2014年，其创始愿景极具理想主义色彩——做“对象存储领域的 Apache”。在那个 AWS S3 统治云存储的年代，MinIO 以其极致的轻量化（单个静态二进制文件）和对 S3 API 的 100% 兼容性，迅速赢得了开发者的青睐。

在这一阶段，MinIO 采用宽松的 Apache 2.0 许可证，鼓励开发者将其集成到各种应用中。其核心价值主张是“让任何硬件都能变成 AWS S3”。这种开放策略极其成功，MinIO 官方宣称其 Docker 镜像下载量超过10亿次，成为全球部署最广泛的对象存储服务 。此时的 MinIO 是云原生技术栈的宠儿，是 Kubernetes 环境中标配的存储后端。

许可证武器化（2019-2025）：AGPL 攻防战

社区关系的第一次重大裂痕出现在2019年至2021年间。MinIO 宣布将其核心许可证从 Apache 2.0 变更为 GNU AGPLv3 。

虽然官方解释称此举是为了防止云厂商（如 AWS、Azure）“白嫖”代码并将其包装为专有服务——这是开源界常见的防御性手段。 这一时期，MinIO 从社区的守护者转变为激进的知识产权捍卫者。 2022 年， MinIO 公开指责 Nutanix Objects 产品侵犯其许可证，撤销了Nutanix 的使用授权；2023 年， MinIO 以类似理由起诉高性能文件系统厂商 Weka。 这些法律行动虽然在法理上具有争议，但释放了一个明确的信号：MinIO 不再欢迎未经付费的商业集成。这为2025年的全面封锁奠定了法律和心理基础。

阉割控制平面（2025-05）

2025年5月，当时 MinIO 决定从社区版代码中移除 MinIO Console——这是一个集成了存储桶管理、身份与访问管理（IAM）、监控和日志审计的关键图形用户界面（GUI）。 此次剥离后，开源版 MinIO 仅剩下一个基础的“对象浏览器”，仅具备查看和下载文件的能力。

而身份策略管理，站点复制配置，生命周期管理等核心运维功能被完全移至商业企业版。 这一变更将社区版 MinIO 从一个功能完备的存储管理系统降级为一个单纯的数据平面组件，剥夺了其作为独立产品在生产环境中使用的控制平面能力

中断二进制分发（2025-10）

2025年10月15日，当时，正值一个关键安全漏洞（CVE-2025-10-15T17-29-55Z / GHSA-jjjj-jwhf-8rgr）被披露之际，MinIO 停止了向 Docker Hub 和 Quay.io 发布更新的 Docker 镜像 。 这一时间点的选择具有极高的战略意味。在重大安全漏洞爆发期间切断二进制分发，实际上是将安全性变成了一种“勒索”筹码。

这一决策直接切断了绝大多数企业级用户的自动化部署链路，使得依赖 docker pull minio/minio 或 helm install 的标准 CI/CD 流程瞬间失效。 对于那些缺乏 Go 语言编译环境或内部容器镜像仓库维护能力的团队而言，这实际上等同于不可用。

维护模式（2025-12）

2025年12月3日，MinIO, Inc. 在其官方渠道及 GitHub 仓库中正式更新了项目状态，宣布 MinIO 开源项目进入“维护模式”。 README 上写到：以后不再提供功能更新改进，不再审Issue合 PR，重大安全问题看情况。 不再提供 RPM/DEB 包与 Docker 镜像，不再加新功能，需要维护的企业用户请切换到商业版本 AIStor 上。

技术影响：对开源生态的破坏

MinIO 进入维护模式对现有技术栈造成了即时且深远的破坏。

CI/CD 管道的断裂与自动化危机

成千上万的 Helm Charts、Ansible Playbooks 和 Terraform 脚本依赖于 minio/minio 或 bitnami/minio 镜像。 随着官方停止发布镜像，Bitnami 等第三方打包商也因无法获取上游稳定代码而被迫停止更新 。

• 连锁反应： 新环境的部署将直接失败；自动扩缩容组（Auto-scaling groups）在拉取新节点时会因找不到镜像而挂起。
• 修复成本： 企业必须重写所有的部署脚本，指向私有镜像仓库，并建立内部的构建流程来从源码编译 MinIO。

安全真空：CVE 管理的私有化

停止发布二进制文件最致命的后果是安全补丁的滞后。以2025年10月的漏洞为例，MinIO 实际上扣留了二进制补丁 。

• 风险暴露： 缺乏专门安全团队的中小企业将被迫继续运行含有高危漏洞的旧版本。
• 合规噩梦： 对于受 PCI-DSS、HIPAA 或 SOC2 监管的企业，无法获得供应商签名的安全更新意味着合规性失效。

运维复杂度的指数级上升

UI 的移除不仅是用户体验的倒退，更是运维成本的增加。 过去只需在 Console 中点击几下即可完成的存储桶策略配置、用户权限分配，现在需要运维人员熟练掌握 mc 命令行工具或编写复杂的 JSON 策略文件。 这无形中提高了使用门槛，使得 MinIO 不再适合作为轻量级的内部工具使用。

背后的原因：资本与商业化的压力

MinIO 的技术决策根本动力来自于资本市场的估值逻辑。截至2025年，MinIO 已累计融资1.26亿美元。 其中最具决定性的是2022年1月完成的1.03亿美元 B 轮融资，由英特尔资本（Intel Capital）、软银愿景基金2期和 General Catalyst 领投。 这轮融资将 MinIO 推上了10亿美元估值的“独角兽”宝座。

在风投逻辑中，10亿美元的估值意味着公司必须展现出通往IPO的明确路径，通常要求年经常性收入（ARR）达到1亿美元以上，并保持高速增长。 2025年2月，MinIO 宣布其 ARR 在过去两年增长了149% 。虽然增速可观，但要支撑如此高的估值，仅靠自然转化已不足够。

停止开源支持，是将庞大的用户基数强制转化为付费客户的最直接手段。

2025年，MinIO 进行了全面的品牌重塑，推出了“MinIO AIStor”，将自己定位为“企业 AI 的数据基石”。 公司管理层意识到，通用对象存储（用于备份、网盘）的市场已是一片红海，且利润微薄；而生成式 AI（Generative AI）对高性能数据吞吐的需求（Exascale AI）才是下一个增长爆发点。 通过优化 AI 工作负载并专注于服务财富500强企业 ，MinIO 实际上决定剥离低价值的开源用户群体。 维护模式的开启，标志着 MinIO 正式从一个广泛的开源项目转型为一家服务于高端 AI 客户的垂直软件供应商

MinIO 已经不是几个极客在车库里写的玩具了，它是一家融资了 1.26 亿美元、估值超过 10 亿美金 的商业公司。 它的背后站着 Intel Capital，站着 软银愿景基金。 当你拿了风投那么多钱，你的老板就不是用户，而是投资人。 投资人要的是什么？是 ARR（年度经常性收入），是 增长率，是 IPO。 你跟投资人说：“我有10亿次 Docker 下载量！” 投资人会问：“这10亿次下载，给你付了一毛钱吗？”

现实就是这么残酷。那帮用免费版 MinIO 的中小企业、个人开发者，在资本眼里就是 低价值资产。 你们提 Issue 报 Bug，群里问东问西，消耗的是昂贵的工程师工时，带宽和服务器资源，而你们 永远不会转化为付费客户。 MinIO 的管理层很清楚，他们的真正金主是那些搞 AI 大模型 的 500 强企业。 那些训练 GPT、跑自动驾驶数据的公司，需要的是 AIStor，是极致的性能，是 7x24 小时的 SLA 。

所以，开启“维护模式”，本质上是一次 资产剥离。MinIO 决定切掉这块“坏肉”（免费用户），把所有资源集中到能产奶的“金牛”（企业级 AI 客户）身上。 从商业策略上讲，这叫 聚焦。 从对投资人的交代上讲，这叫 负责。 只是从开源上来说，这叫 缺德。

老冯的感想

老冯大概从 2018 年开始使用 MinIO ，当时还是 Apache 许可证，我们搞了几个几 PB 的对象存储，用来存放视频，图片，备份 —— 可能是那时候国内最大规模的部署实践。 老冯也编写了 MinIO 部署监控，扩缩容的 Playbook ，算是做过一些贡献 —— 现在还能在 Pigsty 中开源提供。

作为开源创业者，老冯不是不能理解这种改变的动机。 但是站在开源贡献者与用户的立场 —— 老冯也知道很多兄弟现在心里只有一句话：“我从未见过如此厚颜无耻之人。”

开源协议虽然不是卖身契，但它是一种 社会契约。 开发者贡献代码、用户贡献测试场景和口碑，大家一起把项目捧红。 MinIO 享受了十年的社区红利，靠着“全球下载量第一”的虚荣指标拿到了融资， 转头就对这就帮把它捧上去的用户说：“你们是搭便车的，滚蛋。” 这种行为破坏了开源社区最底层的信任。

这种“养套杀”的手段，比币圈的 Rug Pull 还要恶心。币圈割的是钱，MinIO 割的是全球数万家企业的技术栈 —— 用户的选择其实不只是一个二进制，而是一个软件生态和设计哲学。等大家都上车了，把迁移成本堆高到无法承受，然后突然抽走梯子。 这种模式，开源专家 Tison 在《诱导转向的伪开源战略》已经聊的很透聊。

诱导转向的核心问题在于 欺骗，既然 MinIO 背叛了社区，社区也会抛弃它。Garage、SeaweedFS 甚至 RustFS，替代品有很多。江湖路远，后会无期。 如果要说老冯的感想是什么，那么就借用《银河系漫游指南》里海豚临走时说的那句话吧：

—— “So long, and thanks for all the fish.” —— 再见，多谢你们的鱼了。

题外话与更新（2026-02-14），MinIO 官方仓库已经彻底归档并不再维护。 我创建了一个 Fork：pgsty/minio / 文档 https://silo.pgsty.com/zh/。 搭建了 CI/CD 提供 RPM/DEB 二进制包与 Docker 镜像，基于最后的上游版本 2025-12-03 构建，恢复了 2025-05 阉割的控制台能力。

2 - 发布注记

发布日志记录各版本的功能演进、安全修复、依赖更新、兼容性要求与交付制品。

最新的 20261026 联合发布 汇总了 SILO Server、mcli 与 KES 自 20261018 正式版以来的全部更新，并配套发布 Console 2.5.1 与 silo-pkg 3.15.2（10 月 24—25 日的阶段性维护记录已并入正式发布日志，原链接自动重定向至新页面）。

2.1 - SILO 20261026：Server、mcli 与 KES 联合发布

SILO、mcli 与 PGSTY KES 20261026 现已联合发布，配套 SILO Console 2.5.1 与 silo-pkg 3.15.2。本文整合了 10 月 24—25 日的维护记录，完整说明自 20261018 正式版以来的所有变更。三个可执行组件采用统一的发布日期与包版本号；KES 仍作为可选的外部密钥服务独立部署。

发布组件

五个项目统一使用 Go 1.27.3 构建。Server、Console 与 mcli 选用 silo-pkg v3.15.2 以及固定的上游提交 minio-go v7.4.2-0.20261025165926-320af050c445（伪版本，上游尚未打 v7.4.2 标签）。Server 显式集成已发布的 Console 与 mcli 源码；单独升级独立部署的 Console 不会替换旧版 Server 内嵌的控制台界面。详见组件矩阵与下载页。

Server：自 20261018 以来的修改

• LDAP 与 IAM（#250）： 修复规范化 LDAP DN 过长导致无法登录的问题。当合法 IAM 键的单个 ASCII 路径分量超过 255 字节时，可选 IAM 记录读取将其视为“记录不存在”并继续按组策略登录；但无法读取的吊销记录与底层存储故障仍严格按 Fail-Closed 拒绝，且对象后端仍不支持直接写入超长路径记录。此外，策略重载在访问底层存储期间不再持有认证缓存锁，仅在完整加载成功后原子替换缓存并保持 IAM 写入顺序；请求取消信号会传递至 KMS 与 SSE-S3 解密路径，同时不缩短调用方的策略查询超时。
• 内置策略 Reset 与实时桶清单： 对内置策略执行 Reset 后，首次读取即可立即恢复原生策略定义；延迟到达的 peer/etcd 通知会重新加载已提交状态，不会覆盖后续新修改。策略在用检查、删除修订号与自定义策略删除行为保持不变。Console 的 account-info 接口改为读取实时存储桶清单，创建或删除桶后刷新页面即可看到最新结果（对象用量统计仍由后台扫描器异步更新）。
• 多池删除保护（#257、#256）： 普通删除与批量删除改为先清理非权威池中的旧副本，再删除权威池副本，从而在部分失败时保住最新权威副本；同时为新建删除标记选择可用存储池，并保护仍被其他存活副本引用的远端分层对象。
• 版本桶生命周期过期（#253、#252）： 当生命周期过期规则只是追加删除标记时，完整保留上一版本的远端分层数据（包括暂停版本控制桶中的非 null 版本）；只有当历史版本被真正永久清除、且没有任何存活引用依赖其底层载荷时，才回收远端分层数据。
• 分片上传复制（#255、#254）： 为复合 CRC 分片对象复制透传 FULL_OBJECT 校验和类型，避免目标站点因按分片复合模式重算校验和而返回 BadDigest。
• 存储 RPC 与超时语义： 转发存储 RPC 删除选项（包括覆盖写回滚所需的旧数据目录），并保持既有的磁盘/RPC 超时、请求取消、对象锁、读仲裁与自愈策略。正式版在 dcc2f20ba 中撤回了 20261025 草稿里的已接纳 I/O 排空等待与逐对象变更锁方案（含 #258），详见多池对象一致性设计记录。
• 依赖、打包与交付： 更新 SFTP、etcd、NATS 及云厂商 SDK 等 Go 依赖；保留 Kafka 2.1 默认协议版本、CLI 输出格式与 NetBSD 兼容版本；修复旧版 DARE v1 解封逻辑（新写入继续使用 v2）。容器镜像、校验安装脚本与 Helm 客户端任务统一内置 mcli 20261026。Windows 归档改用 ZIP 格式，静态构建 curl 升级至 8.23.0 并附带下文的证书信任配置说明；同时修复了最终刷新 SBOM 与构建溯源时的 RPM 签名校验。
• 文档与迁移： 合入单节点 MinIO 迁移指南（#228），校准运维默认参数说明，并将升级流程统一收敛至迁移指南。

本版完整保留 20261018 已交付的 Object Lock、IAM 授权、持久 STS 吊销、跨池迁移与 LIST 恢复修复。文末的依赖安全清单将本轮新合入的修复、历史修复与未使用代码中的扫描告警分别列出。

mcli：自 20261018 以来的修改

• 客户端身份缓存隔离（#50、#55）： S3 与管理客户端缓存按凭据、证书信任、代理、DNS 解析器及自定义请求头隔离，同时保留凭据自动刷新与 Web Identity token 文件轮换。
• 复制 Resync 状态与速率计算（#48、#49、#52）： admin replicate resync status --json 会持续消费状态流直至到达 Completed、Failed 或 Canceled 终态，完整保留已完成任务的状态输出；当桶未启用复制时明确输出结果，TTY 模式在遇到 Failed 或 Canceled 时立即结束等待；同时修复了累计传输超过约 8.6 GiB 后吞吐量计算的整数溢出。
• 诚实的退出码（#51）： resync start 与 resync cancel 在部分桶操作失败时保留逐桶错误详情并返回非零退出码；用 resync status 成功查询到一个已处于 Failed 或 Canceled 状态的任务仍正常退出 0。admin info --json 在请求失败时同样返回非零退出码，并保留 JSON 错误输出。
• 批处理状态观察（#53、#54）： batch status 在实时指标暂缺时继续观察并输出新增的 pending 状态（不再把排队中或缺样本的任务误判为已完成），在指标流中断时通过带超时边界的持久化状态查询兜底，并修复了超大对象计数下的 IOPs 整数溢出。
• 别名区域配置（#44）： 支持按 MC_REGION、AWS_REGION、持久别名配置中的 region 字段、自动发现的优先级解析区域，并在客户端缓存中隔离签名区域（未新增 alias set --region 命令行参数）。
• 底层 SDK 修复： 拒绝被截短的顺序或并行分片读取流；修复 ReadAt 的 EOF 处理、负偏移校验及 Stat 之后的读取/Seek 边界；对批量删除回退路径中的重复错误去重；移除桶复制配置时同时接受 HTTP 200 与 204（403 等真实鉴权或请求错误仍正常报错）。
• 打包与帮助信息（#45）： 升级至 Go 1.27.3 与 GoReleaser 2.19.0，Windows 归档改用 ZIP 格式；更新命令行帮助链接以及已停用的服务端自更新/SUBNET 命令提示，保留全部既有 CLI 配置与 MC_* 环境变量兼容。

自动化脚本请适配 batch status 新增的 pending 状态，以及 resync start/cancel 部分失败时的非零退出码。本次客户端升级无需变更服务端协议。下载流中途断开仍会立即报错；分片上传被 SIGINT 中断时以退出码 130 退出，未完成的分片可能需显式清理。详见完整客户端提交历史。

KES：自 20261018 以来的修改

KES 20261026 汇总了 Go 1.27.3 与云厂商 SDK 依赖维护，将二进制、Linux 软件包与容器镜像统一对齐到 20261026 批次。HTTP API、配置文件格式与后端存储密钥格式保持完全兼容。

全套 25 项模块更新还包含 AWS 配套模块与 Google 生成的 API 库；终端输出与 YAML 解析继续固定在 Lip Gloss v1 与 gopkg.in/yaml.v3。构建工具升级至 GoReleaser 2.19.0（nFPM 保持 2.48.0）；Linux 软件包仅安装 /usr/local/bin/kes 可执行文件，不会自动启动未配置的服务。

兼容性回归测试覆盖了 OpenBao KV v2 与本地 Moto Secrets Manager 协议夹具，验证了升级前后写入的加密对象读取、版本回滚以及 Server 冷重启解密。生产环境升级时请保留持久化根密钥、证书与配置，并在重启 Server 后实际执行读取解密验证。详见 KES 完整提交历史。

Console 2.5 与 silo-pkg 3.15

Console 2.5.1 包含了 2.5 系列的整体界面重构、按权限裁剪导航、Overview 集群概览、对象预览、Tasks 任务中心、身份管理以及高延迟网络下的诊断流修复；2.5.1 补丁版进一步修复了启停用户组时保留既有成员、OIDC 字符串数组组权限、反向代理后的安全会话 Cookie、准确的凭据 JSON 导出、流式 ZIP 错误状态码以及键盘焦点与无障碍标签。Server 20261026 已直接内嵌此版本。

silo-pkg 3.15.2 汇总了 3.15.0 的 Go 1.27.3 与依赖升级、3.15.1 的上游 SDK 修复，以及 3.15.2 移除复制配置时的 HTTP 204 状态码兼容，同时完整保留既有策略语义与 3.14.3 的策略匹配性能优化。silo-pkg 仅作为 Go 源码模块发布，嵌入方需重新编译以纳入更新。

升级与故障边界

1. 协调升级： 升级前请备份 IAM 状态、配置文件与加密密钥，并按 IAM 升级指南同步升级集群内的所有 Server 节点与跨站复制站点。不支持新旧版本进程长期共用同一 IAM 后端或执行滚动降级。
2. 升级后核验： 逐一验证 LDAP/OIDC 登录、内置策略 Reset、存储桶清单刷新、多版本读取、跨站复制与加密对象解密。分片对象 FULL_OBJECT 校验和复制修复需要先升级发送端 Server，再检查待复制队列。
3. 归档格式与脚本适配： Windows 平台归档已改为 .zip（Linux 与 macOS 保持 .tar.gz）；自动化脚本请适配 mcli batch status 的 pending 状态与 resync start/cancel 部分失败时的非零退出码。既有环境变量、配置文件名与磁盘存储格式保持不变。
4. 已知功能边界： 公开的 ListMultipartUploads 仍使用节点本地内存缓存与精确对象键查找，已退役的 strict 开关会被忽略并打印警告；#79 与 #217 尚未关闭，Webhook 热重载 PR #249 未纳入本版，更大范围的性能问题仍在 #251 中跟踪。

存储超时与一致性边界： 客户端收到请求超时并不代表底层磁盘或 RPC I/O 已经停止，也不代表该次写入一定没有提交。在部分磁盘故障、锁租约过期或网络分区下，仍可能出现迟到提交、延迟回滚或短暂读到旧值与旧标签。本版未引入分布式锁 fencing，也不会自动恢复升级前已经损坏或丢失的对象、远端分层数据与元数据。

下载与验证

各平台的二进制文件名、SHA-256 校验和、Linux 软件包与验证说明见下载页面。版本化容器镜像可直接拉取：

docker pull docker.io/pgsty/silo:RELEASE.2026-10-26T00-00-00Z
docker pull docker.io/pgsty/mc:RELEASE.2026-10-26T00-00-00Z
docker pull docker.io/pgsty/kes:RELEASE.2026-10-26T00-00-00Z
docker pull docker.io/pgsty/silo-console:v2.5.1

• Server 标准镜像（Linux amd64/arm64 多架构 manifest）：sha256:7bb2aff6b89efe1cb1303c10fc21d579447434ed06649ac9ec05a5e2dbf30ad7（与 latest 一致）
• Server distroless 镜像（Linux amd64/arm64 多架构 manifest）：sha256:e6544a902f426f2b4e775b89f3c1cd78310dbffc262d1ed82e9800c1cb1b5885（与 distroless 标签一致，两个架构均保留 silo healthcheck ready 原生健康检查，见 Server 镜像构建流水线）

各组件的发布制品均通过固定源码提交、归档校验和、软件包签名与构建溯源（Provenance）独立标识：

• Server 制品验收： 核验了对应源码 c3ad836aed0d 的 36 项发布资产与 34 项构建溯源证明（含 6 个平台归档与 6 个 Linux 软件包），两个架构的 RPM 包均已完成 GPG 签名，校验清单、SBOM 与溯源证明同最终软件包完全一致（见 Go CI、VulnCheck、Release 与 Finalize 流水线）。
• 本地多节点与故障注入验收： 在 Linux arm64 环境下完成了基线四节点 88 项、升级后四节点 88 项与八节点多池 136 项 S3 兼容性检查；历史对象、标签、加密对象及跨升级周期的分片上传均完整保留。在滚动重启、SIGKILL 强杀与 75 秒进程挂起恢复测试中，408 个已确认写入的对象全部完整读回，哈希与列表校验全部通过；原生可信 TLS 下的 mcli 测试套件与 16 项持久化检查同样全部通过。注意集群健康检查端点仅反映节点上报的磁盘仲裁状态，在滚动重启或升级后恢复流量前，请按启动就绪窗口指南验证实际数据面读写。
• KES 制品与集成验收： 核验了 19 项公开资产、11 项构建溯源证明及两个签名 RPM 包。使用实际构建的 Darwin arm64 KES 二进制，先后搭配 SILO 20261018 与最终版 Server/mcli 20261026 Linux arm64 二进制完成了 OpenBao KV v2 与 Moto 升级、回滚及 Server 冷重启测试。两个架构的 KES 容器镜像内置二进制与发布归档一致，多架构镜像摘要为 sha256:ea36fcdd260c606eb89e693b0949aea73b149359605273a98fcf13c8433049cd（见 KES 制品流水线与镜像流水线）。

贡献者与完整历史

感谢 Denis Babchuk / @botdeniska 贡献生命周期、复制与多池删除修复，@910patin 修复长 DN LDAP 登录，Azat / @azataiot 定位并复现高延迟健康报告截断问题，@MikeVL 报告 resync 速率溢出与 JSON 状态输出问题，@mrjavadseydi 贡献别名区域配置支持并提出 Webhook 热重载方案，Gerald Combs / @geraldcombs 提出 Windows ZIP 归档建议，@yupoet 贡献单节点迁移指南，以及 @GhaziTriki、@devTeam-AiReg 与 @sargarass 报告的问题与反馈。

下表汇总了本发布周期内五个组件仓库中合并、采纳或跟踪的社区 Issue 与 PR：

社区贡献者名册收录了所有参与过 Issue 或 PR 的社区成员。各仓库的完整提交对比：Server、mcli、KES、Console、pkg。

以下为 10 月 22—25 日的依赖与安全审计记录（多个组件共用的依赖按对应软件包合并列出）：

10 月 24 日追加的 Go 依赖更新

Go 工具链维持 1.27.3。相对 10 月 22 日的候选依赖，本轮纳入 26 个新发布的第三方模块版本，并同步升级 Arrow 与 codescan，共更新 28 个模块：

本轮更新保持既有公共 API 与输出格式不变；各组件最终锁定的模块版本见上文组件清单。

已纳入的运行时安全修复

Go 与证书信任

CVE-2026-111943 / GO-2026-6809：Go 1.27.3 在 crypto/x509 证书链校验中直接拒绝已知失信的中间证书，在操作系统信任库尚未更新时也能提供兜底拦截。五个主项目及全部独立调试工具均统一使用 Go 1.27.3 编译。

此外，SILO、mcli 与 KES 的 UBI 容器信任库已应用 Red Hat RHSB-2026-012 的根证书封禁列表。由于根级封禁会一并拒绝挂靠在这些根证书之下的所有证书链，其拦截范围比 Go 1.27.3 的中间证书黑名单更广；若外部服务仍使用受影响根证书签发的证书链，需先行更换证书。发行版 CA 软件包的跟进状态见下文本地缓解。

SFTP 依赖安全加固

pkg/sftp 1.13.12 修复了 10 月 23 日公布的三项安全问题。截至本次核对，它们均没有 CVE 编号，以下按 GHSA 单独记录，不计作新增 CVE：

上游后两条公告的受影响版本区间（affected range）与修复版本字段存在矛盾，本次直接升级至包含实际代码修复的 1.13.12 并通过回归测试验证（当前 Go 漏洞库快照停留在 10 月 21 日，尚未收录这三条 10 月 23 日发布的公告）。

静态 curl 及其链接库

SILO 容器镜像内置的静态 curl 从 8.22.0 升级至 8.23.0（启用 HTTP/2、SSH 与 Brotli，TLS 后端采用 OpenSSL）。下表完整列出 curl 8.22.0 官方漏洞汇总中的 21 个 CVE 及其在当前静态构建中的适用情况：

静态链接的 Alpine 底层库同步升级至以下回补版本（-rN 代表含安全回补的 Alpine 修订号）：

此前发布的 SILO arm64 镜像静态库清单已包含 OpenSSL 3.5.9-r0、nghttp2 1.70.0-r0（CVE-2026-58055）与 zlib 1.3.2-r1（CVE-2026-85091）；本次在构建脚本中显式锁定上述最低安全版本并完成双架构验证。Alpine 修复修订详见官方安全元数据。

构建与开发工具安全修复

本节记录 SILO Console 前端资源构建、代码生成与测试环境（生产环境运行的是编译后的 Go 服务端二进制），以及仓库内独立的 Go 调试模块。

Node 24.22.1

构建环境的 Node.js 从 24.22.0 升级至 24.22.1。下表列出 Node.js 2026 年 10 月安全公告中适用于 Node 24.x 的 8 个 CVE（不含仅影响 Node 26 的条目）：

Node 24.22.1 内置的 Undici 从 7.29.1 升至 7.30.1，包含以下 8 项修复（详见 Undici v7.30.1 发布说明）：

Node 24.22.1 内置的 OpenSSL 从 3.5.8 升至 3.5.9（旧 Node 24.22.0 仍停留在 3.5.8），涵盖 DTLS、QUIC、CRL、CMP、EC / SM2 与握手内存安全方面的 13 项修复：CVE-2026-84782, CVE-2026-35189, CVE-2026-35191, CVE-2026-42772, CVE-2026-54872, CVE-2026-54873, CVE-2026-54875, CVE-2026-72897, CVE-2026-75804, CVE-2026-75805, CVE-2026-75806, CVE-2026-77696, CVE-2026-84784。

Node 24.22.1 内置的 c-ares 从 1.34.8 升至 1.34.9，修复了 11 条尚未分配独立 CVE 编号的上游 GHSA 公告（其中 GHSA-wpr3-8q3r-4q8c 补齐了此前 CVE-2026-33630 修复遗漏的连接关闭路径，上游仍标为 No known CVE）：

前端依赖与代码生成器

此外，代码生成工具 go-swagger 从 0.33.2 升级至 0.36.6，修复 GHSA-8gmg-wf5j-hvf7 与 GHSA-rg22-m539-jwvf（不可信 OpenAPI 规范中的内容类型或枚举值在代码生成阶段可能触发代码注入，上游首次修复版本为 0.35.3，无独立 CVE 编号）。生成文件已与新版工具同步；生成流程显式保留经过审查的配置导入绑定器与 multipart 处理方式，并通过回归测试保留原有文件大小、文件名和表单编码行为。

独立 Go 调试模块

服务端仓库下的 inspect、s3-verify 与 xattr 三个独立调试模块此前落后于根模块版本。本次同步消除了 37 个带 CVE 编号的依赖版本告警及 1 个无 CVE 的 S2 公告：

下表列出对应的 Go 官方漏洞库条目与上游首次修复版本（OpenPGP 的无修复公告单列于下文其他残留项）：

上游或发行版仍未解决的条目

截至 2026-10-23，以下条目在上游或所选操作系统发行版中尚无可用修复版本。我们保留原始扫描记录，并逐项说明已采取的本地缓解措施或运行时可达性边界。

已做本地缓解，等待上游发布

UBI 9.8 尚无适用发行版补丁的扫描记录

2026-10-22 对 SILO、mcli 与 KES 在 amd64 和 arm64 上的系统组件验收镜像（包含最终静态 curl 与 CA 证书库）进行了扫描：每个镜像均保留 24 条 RPM 记录，对应同一组 12 个唯一 CVE（15 条 Medium、9 条 Low，无 High / Critical，所有记录的 FixedVersion 均为空）。2026-10-23 复查 Red Hat 安全数据时，以下 RHEL 9 源包状态仍为 Affected 或 Fix deferred。

由于 RPM 扫描器按源包（SRPM）映射漏洞，部分仅存在于未安装命令行工具或其他 CPU 架构中的缺陷也会挂靠到基础运行库（如 libgcc、glibc）名下；下表逐一列出各条目的实际适用范围：

构建阶段与无 CVE 公告

• Alpine 构建阶段宿主包的 curl / libcurl 仍为 8.22.0-r0：截至 2026-10-23，Alpine 双架构包索引尚未推送 8.23.0。该包仅在容器构建阶段用于下载固定 SHA-256 校验和的源码包，最终打入运行镜像的是从源码编译的静态 curl 8.23.0。
• GO-2026-5932：golang.org/x/crypto/openpgp 已废弃且无上游修复版本（无 CVE 编号）。虽然 golang.org/x/crypto 仍在模块图中，但已核查的构建目标均未导入受影响的 openpgp 子包。

已有历史修复，不属于本次新增漏洞

按模块路径匹配的二进制扫描器仍会对 SILO 报告 CVE-2025-27414、CVE-2026-33322、CVE-2026-33419、CVE-2026-34204、CVE-2026-39414、CVE-2026-40344、CVE-2026-41145、CVE-2026-42600（因为 SILO 保留了 github.com/minio/minio 模块路径，而上游通告使用开放版本区间）。这八项缺陷在此前版本中均已修复并通过回归测试，详见 SFTP 公告、OIDC、LDAP、复制元数据、CSV、Snowball、签名校验 与 ReadMultiple。

兼容性与依赖回归证据

为避免已复现的终端表格输出变化、字符宽度计算差异及 NetBSD 交叉编译回归，本次固定保留 tablewriter 0.0.5、go-humanize 1.0.1、根模块 go-runewidth 0.0.29 及 go-systemd/v22 22.6.0（xattr 模块保留其既有宽度库组合）。此外：

• Kafka 通知目标在应用用户配置前显式保留协议版本默认值 2.1；
• DARE 加密继续使用 32 字节密钥与 v2 写入格式，并修复旧 v1 解封缓冲区处理；
• pgzip 保留对缺失校验尾部返回 unexpected EOF 的完整性检查。

10 月 22 日至 23 日的候选构建（与回退基线均基于 Go 1.27.3，持久化验收在单节点四盘 Linux arm64 环境执行）已完成以下验证：

• 全量编译、适用的 -race 与 lint 检查；
• 加密对象在新旧依赖栈之间的互读与回滚验证；
• 服务重启、缺失分片自愈恢复与 CLI 格式化输出校验；
• Console 真实对象上传下载、ZIP 归档预览、WebSocket 会话及监控指标图表验证。

10 月 24 日追加升级后的候选源码另行完成以下验证：

• silo-pkg、mcli、KES 的全量 race 测试，Console 的 API / pkg / cmd race 测试，以及 SILO 的全量测试和 SFTP、IAM、Parquet 专项 race 测试；五个项目的 lint、模块校验与依赖整洁性检查通过。
• SFTP 自有驱动在 HTTP / HTTPS S3 后端上的对象读写、列表、删除、Unicode 文件名、传输块边界和只读权限保护；上游只读服务与符号链接删除回归测试通过。旧、新依赖均通过新增的对象操作测试。
• JWX 签名与时间声明边界对照通过；68 项 CLI 输出对照无新增差异，仅对既有元数据映射顺序做归一化。
• 本地 etcd 服务的 mTLS、账户认证、事务、watch、lease 和旧→新→旧客户端跨服务重启读取；NATS / STAN 的消息持久化、ACK、持久订阅游标及断线重连通过。
• Azure / GCS 本地协议夹具、KES GCP Secret Manager 操作与分页、Azure SDK 的 Arrow 解码测试、procfs 完整上游解析夹具测试通过。procfs 更新包含 bcache 单位及 NVMe 大小的解析修正，相关指标数值可能随之纠正。
• mcli、Console、SILO、KES 的 Darwin arm64 原生构建与 Linux amd64 交叉构建，以及 mcli、SILO 的 NetBSD amd64 交叉构建通过。

本轮五个项目的 Linux amd64 包级 Go 漏洞扫描未发现受影响的已导入包（仅余未导入受影响子包的模块级 GO-2026-5932 记录）。

2.2 - SILO 20261018 发布说明

Server 20261018 已正式发布，提供 amd64 与 arm64 版本化归档、原生软件包及 Docker Hub 标准／distroless 镜像。本版本接替 Server 20260916（20261015 保留为已撤回的历史草稿记录）。

版本化归档、原生软件包及固定标签的容器拉取命令见下载页。

Object Lock 与 IAM 安全修复

SN-2026-015 / SN-2026-016 — Object Lock 保留期授权与原位覆写防护。 #234 与 #235 修复了保留期修改鉴权与原位覆写漏洞：

• 每次 PutObjectRetention 请求在读取目标对象前，都会携带请求中的 Object Lock 条件键校验 s3:PutObjectRetention。缩短、清空未到期的 GOVERNANCE 保留期或切换其模式时，调用方必须同时提供 x-amz-bypass-governance-retention: true 请求头并具备 s3:BypassGovernanceRetention 权限（不能替代基础 s3:PutObjectRetention 权限）。清空保留期时剩余天数按 0 计算；未到期的 COMPLIANCE 保留期不允许缩短或更改模式。
• 调用方显式指定写入 versionId 时必须具备可信复制身份（s3:ReplicateObject）。目录对象的 null 版本和已持久化的分片上传目标会在对象写锁内重新校验锁状态；锁状态读取失败时按 fail-closed 拒绝写入，既有 Legal Hold 继续生效。请同步升级集群中所有写入节点及接收 S3 请求的复制站点。详见安全公告与修复设计。

SN-2026-017 — 管理凭据自助授权边界。 #242 使凭据自查询与清理严格遵守显式 Deny、会话策略收窄（sessionPolicy）及外部授权插件判定。在内置授权下，受限会话凭据无法创建或更新权限超出自身范围的服务账号，非 root 管理员也无法修改 root 派生的凭据；无限制空策略继承与损坏的非 root 密钥清理保持支持。后续提交 995439260 将批量自查询别名归一到父身份，并保留无附加策略普通用户的自查询能力，无需新增 Admin action 或迁移 IAM 存储。详见安全笔记与授权契约。

按范围撤销 STS 令牌

0cd388c66 让 RevokeTokens 同时枚举持久化 STS 身份记录与节点内存缓存，即使某个节点此前漏掉了令牌签发通知，也能完整撤销目标令牌。即便批次中个别令牌写入墓碑失败，已提交的删除记录仍会广播给同集群节点与站点复制对端；离线站点在恢复后通过既有 IAM 删除自愈补齐。基于对象存储和 etcd 的缓存刷新也会在通知或 watch 遗漏后自动剔除已撤销令牌。

撤销范围仍为请求指定的父身份及可选令牌类型（覆盖请求集群在操作截点前的快照，不影响新签发的令牌、无关用户或父身份策略）。持久枚举仅增加管理端撤销命令的开销，不为日常请求鉴权增加网络查询。详见 STS 撤销设计与成本。

重平衡与池下线一致性

60c7179dd（含 #248）与 1748f62c7 防止 rebalance 或池下线（decommission）搬迁旧副本时覆盖其他存储池中的最新副本。搬迁流程会在共享对象锁内复核源版本（包含分片完成与分层对象元数据），保留 null 与 UUID 删除标记，并仅清理已确认搬迁完成的版本，不再粗暴删除整个源前缀。若期间发生并发写入、删除或目标池变化，清理会安全中止并留待重试。

退役旧存储池前，请按多池对象一致性设计核验对象版本、标签和删除标记状态（跨站点删除标记的独立边界仍由 #217 跟踪）。

普通对象列表恢复

#239（含原 #221 工作，关闭 #218）修复了在符合恢复条件的元数据分歧下，ListObjects / ListObjectsV2 成功返回却遗漏可读对象 key 的问题。多池合并层会在对象读锁内复核存在分歧的同名条目组：返回当前可读元数据、略过已确认不存在的对象，或在无法确认时返回 503 SlowDownRead 等明确错误。分页生产者出错会终止整次扫描；客户端应消费所有分页并将任一分页错误视为不完整列表。

常规无分歧条目继续走原有的无锁快速路径。锁内复核仅针对符合条件的最新对象组，不降低读仲裁要求，也不新增持久化元数据；请求取消可随时中断锁重试等待，遇到恢复锁冲突时仅执行一次有界短等待。后续提交 3dd53eb81 与 2080b3d03 确保当同名碰撞对象被确认为不存在时，同名目录或公共前缀（CommonPrefixes）仍被完整保留。实测延迟与锁开销见列表恢复锁成本记录。

分片上传列举与清理

回退默认磁盘扫描，恢复 Legacy 内存列举。 #243 在 10 月 17 日引入的默认磁盘扫描已由 4733e1423 撤回。公开 ListMultipartUploads 在空 prefix 时查询节点本地内存缓存，在非空 prefix 时按精确对象 key 查找；进程重启或请求落到其他节点可能遗漏未完成上传（跨池持久化列举仍在 #79 中跟踪）。

与 20260916 相比，环境变量 MINIO_API_MULTIPART_LISTING=strict 已停用：设置该变量会在启动时输出警告并被忽略（旧共享配置键 api multipart_listing 同样被容忍忽略）。但 20260916 引入的上传创建身份元数据、UploadID 路径校验、取消目标匹配检查以及成功取消后的缓存/对端清理通知均得以保留。只读管理诊断接口 multipart-preflight 仍要求 admin:StorageInfo 权限并返回 mode=legacy，其扫描条目数、超时与并发上限仅作用于显式管理诊断。详见分片列举设计、回退原因与容量基准及配置参考。

后台过期分片清理（默认 24 小时过期、每 6 小时巡检一次）包含两项修复：

• #236：优先解析原生上传目录名中的时间戳，再回退尝试 Base64 兼容路径，消除无谓的磁盘元数据读取。
• 0f9199e0c：删除过期上传子目录后，立即清理变空的父目录，不再因删除子目录刷新了父目录 mtime 而多等一轮 24 小时过期周期（非空父目录与活跃上传不受影响）。

错误分类、元数据复用与其他修复

配套组件与依赖

独立发布的 Console v2.4.2 与 mcli 20261018 依赖 silo-pkg v3.14.2；Server 主模块升级至 v3.14.3（优化管理 action 分类性能，授权语义不变），并显式 require 上述 Console 与 MC 版本。

minio-go v7.4.1 包含上传失败时的取消清理、UTC 保留期时间戳及 STS 时长透传。核心依赖更新包括 go-jose v4.1.6、ldap v3.4.15、compress v1.20.3、msgp v1.6.5、etcd v3.7.2 与 golang.org/x/*。注意：升级后的 go-jose v4.1.6 会拒绝超过 4096 位的 OIDC/JWK RSA 密钥，使用超长 RSA 密钥的部署在升级前须先核验 OIDC discovery、JWKS 与登录链路（详见依赖安全说明）。

发行流水线固定使用 GoReleaser v2.18.3、nFPM v2.48.0、golangci-lint v2.15.0 与 govulncheck v1.9.0，并将 Object Lock 竞态回归设为发版前置门禁。make rebrand-guard 改用 git grep 扫描源码并显式报告读取错误，不再依赖外部 ripgrep（7007c164a）。注意仓库内置的 Helm Chart 默认镜像标签仍为 20260916，通过 Helm 部署本版本时请显式覆盖为 RELEASE.2026-10-18T00-00-00Z。

升级与回滚要点

1. 备份状态与固定制品：记录当前运行版本并固定目标二进制或镜像 digest；按迁移指南与 IAM 恢复流程完整备份 IAM 存储、配置与加密材料（常规在线 IAM 导出不包含撤销墓碑历史）。
2. 全集群同步切换：协调升级所有 Server 节点与接收写入的复制站点，切勿在同一 IAM 后端混跑新旧二进制或执行跨版本滚动降级。
3. 核对 Object Lock 与服务账号权限：使用业务实际凭据验证保留期修改、Legal Hold、服务账号创建/更新、自助操作显式 Deny 以及 root 凭据管理。此前因策略格式受损而无法使用的到期密钥，应由授权父身份重新签发。
4. 移除 strict 分片列举依赖：若此前在 20260916 上启用了 MINIO_API_MULTIPART_LISTING=strict，升级前请确保客户端自行维护待完成或待取消的 bucket/key/UploadID，不要依赖公开列表进行全量发现或空间回收判断。
5. 检查列表、重试与 OIDC/TLS 链路：验证普通与分页 LIST、PUT/分片完成对 503 SlowDownWrite 的重试、OIDC/JWKS 密钥长度及经过 TLS 检查设备的出站连接（参见 Go 1.27 TLS 与 OIDC 指南）。
6. 回滚风险：降级回 20260916 会重新暴露本版修复的 Object Lock 与管理凭据授权缺陷，且升级本身不会自动恢复升级前已被覆写的对象版本或丢失的标签。

制品核验与验收记录

签名标签 RELEASE.2026-10-18T00-00-00Z 及全部 36 个发行制品均对应源码 0cd388c666f8211f552604ae73448a066e9c25ce，并通过了 Go CI、VulnCheck、Release 构建与软件包定稿工作流。

• 静态制品核验：核验全部下载摘要、6 个平台归档版本戳、6 个系统软件包（RPM/DEB/APK）载荷、34 份构建来源证明（attestation）、2 份 Sigstore 校验清单签名、2 份 RPM 签名与 12 份 SBOM。
• 本机功能与故障验收：在原生 Darwin 与 Linux 环境下完成 S3/IAM/STS/Object Lock、LDAP/OIDC、20260916 原地升级、桶复制与站点复制、含内嵌 Console 的三站点恢复、三站点及四进程共享集群 STS 撤销，以及 4 组真实多池迁移（2/3 池 × rebalance/decommission）。在 8 进程 2 池拓扑下，滚动重启负载完成 2,896 次全量扫描，故障恢复负载完成 1,270 次全量扫描，零漏项、零重复、零读取损坏；另有 3 组 Linux 软件包生命周期与 8 种容器运行变体全部通过（注：Windows 与 Darwin amd64 为静态核验，容器 amd64 运行于跨架构模拟环境）。
• Docker Hub 公开摘要：
  • 标准镜像（及发布时的 latest）：sha256:2636fc4155d9a7e41ff58cdb65ddd13ba9304e67184e13c25bc5cb34016269d7
  • Distroless 镜像：sha256:472f59c7be537571f0f9a2ee6b8fe033a220939d521255bd4bf5339e53db7218

感谢 szopi00 报告 Object Lock 问题；mr javad seydi（@mrjavadseydi）贡献原始 LIST 与分片工作；Julien Laurenceau（@julienlau）修复提交元数据分类与结构体复用问题；clown15 修复上传目录清理；cbornet 与 yupoet 改进校验和错误文案；AleksaMCode 修复 Lambda 目标集合判空；以及 Denis Babchuk（@botdeniska）贡献 #248 迁移防覆盖修复与 silo-pkg 性能优化。

2.3 - silo-pkg 3.14.3 发布

发行版： v3.14.3 · 源码： e9d585ba1e7a。依赖基线见 v3.14.2 发布说明。

github.com/pgsty/silo-pkg/v3 v3.14.3 优化了 IAM 策略判定期间识别 admin: 动作的开销，被 Server 20261018 选用。

AdminAction.IsValid 与 HasResource 现在优先执行精确查表，再按需扫描动作集合：不含通配符且未命中的字面量动作直接返回；前缀无法匹配 admin: 命名空间的通配符模式直接跳过合法性扫描，而 adm*、a*d*m*i*n* 等通配模式保持原有匹配语义不变。

性能与验证

在 Apple M5 Max（Go 1.27.2）上进行的 6 轮交替单核基准测试表明：在先遍历 100 条不匹配桶授权、最后命中目标授权的策略场景下，单次策略判定中位耗时从 303.2 µs 降至 54.4 µs（降低约 82%），且零新增堆内存分配。

验证覆盖 Go 1.26 与 1.27 race 测试、lint、LDAP 集成测试、漏洞扫描、60 秒等价性模糊测试（fuzzing），以及针对 50,000 份策略、970,020 次策略判定的新旧版本全量结果比对；使用 mcli 20261018 连接基于新旧包构建的 Server 结果完全一致。

采用方式

公开 API、策略格式、权限判定结果、外部依赖与 go 1.26 最低版本要求均无变化。Server 20261018 采用 v3.14.3，而独立发布的 mcli 20261018 与 Console v2.4.2 继续使用 v3.14.2（各组件依赖版本见组件矩阵）。

感谢 Denis Babchuk（@botdeniska） 提交 PR #11，以及 Klaus Post（@klauspost） 的原始优化工作。

相对 v3.14.2 的完整变更

2.4 - PGSTY KES 20261018 发布

发行版： RELEASE.2026-10-18T00-00-00Z · 软件包： 20261018000000.0.0 · 源码： 2f7e741db905。

这是 PGSTY 维护的密钥加密服务（Key Encryption Service，KES）首个正式发行版。KES 是独立部署的无状态服务，供需要外部 KMS 的 SILO 服务端加密场景使用（参见组件版本矩阵）。

变更内容

• 建立 PGSTY 维护与发布流水线，完整保留上游版权、署名及第三方许可证。可执行文件与系统软件包保持 kes 命名，Go 模块路径保持 github.com/minio/kes。
• 升级至 Go 1.27.2 并刷新依赖，将 AWS Secrets Manager 后端从已弃用的 AWS SDK for Go v1 迁移至 AWS SDK for Go v2。完整保留 YAML 配置字段、显式凭据优先级、自定义端点与密钥存储格式（继续忽略 ~/.aws/config 与 SDK 环境变量端点覆盖）。
• 完整兼容既有 KES HTTP API、MINIO_KMS_KES_* 环境变量、存量根密钥及已加密对象；现有 SILO + KES 部署可直接升级，无需迁移密钥。
• 新增 SILO 搭配 OpenBao KV v2 及 Moto Secrets Manager 模拟器的升级、回滚与重启集成测试（每次版本切换均强制重启 SILO 以排除服务端密钥缓存干扰）。
• 提供签名 Git 标签、GitHub 构建来源证明、GPG 签名 RPM 包与非 root 容器镜像；禁用内置 kes update 自更新命令。

部署与升级

在服务端加密链路中，SILO 负责加解密对象数据，KES 负责验证客户端 mTLS 身份并封装/解封装数据加密密钥（DEK），OpenBao 负责持久化存储主密钥（KEK）。因此，MINIO_KMS_KES_ENDPOINT 必须指向 KES，而非直接指向 OpenBao（架构边界与故障恢复要求见 KES 与 OpenBao 设计说明）。

生产启动 KES 前须配置 TLS 证书、mTLS 客户端身份策略与持久化密钥后端（开发模式仅将密钥保存在内存中）。官方容器默认以非特权 UID/GID 1000:1000 运行，挂载的配置文件与证书须对该用户可读；Linux RPM/DEB/APK 软件包安装 /usr/local/bin/kes，不会自动拉起未配置的服务。

升级前请先备份底层密钥存储与配置文件；升级后验证存量加密对象解密、新加密对象写入，以及重启 KES 与 SILO 后的冷读能力。

交付与验证

全部 19 个发行附件（Linux/macOS/Windows 的 amd64/arm64 共 6 个平台压缩包、6 个 Linux RPM/DEB/APK 软件包、归档校验清单与 6 份软件包校验文件）均已核验，涵盖下载摘要、二进制源码/平台标记、软件包载荷、2 份 RPM 签名及 11 份 GitHub 构建来源证明（见发布工作流）。

官方多架构容器镜像 docker.io/pgsty/kes:RELEASE.2026-10-18T00-00-00Z（linux/amd64 与 linux/arm64，Docker 发布记录）的索引摘要为：

sha256:c2d1a63d15052dfd2854bec9db3fc6846dd74fd6fdf43079f338f36e7a3d5f04

维护验收矩阵重点覆盖 SILO + PGSTY KES + OpenBao KV v2（含 mTLS 认证、OpenBao AppRole 访问、DEK 加解密、重启持久性、未认证请求拒绝，以及与 SILO 20260903/20260916 和上游 KES 2025-03-12T09-35-18Z 的互操作与回滚测试；AWS Secrets Manager 后端通过本地 Moto 模拟器完成协议与存储回归）。

下载 KES · 配置与安装文档 · 制品核验指南 · 相对上游源码差异。

2.5 - SILO Console 2.4.2 发布

版本： v2.4.2 · 源码： ef2dd2c41d21。

本版本作为独立 Console 发行版及 Server 20261018 的内嵌 Console 组件发布（参见 silo-pkg v3.14.2 发布说明）。

更新内容

• 升级至 mcli 20261018、silo-pkg v3.14.2 与上游 minio-go v7.4.1。SDK 包含取消后的失败分段上传清理、UTC 保留期时间戳及 STS 时长透传（并行 GET 与 ComposeObject 仍需显式启用）。
• 保留桶版本控制操作中被包装的底层 S3 错误；当 Object Lock 阻止暂停版本控制时，明确向前端返回 InvalidBucketState。
• 使用 Go 1.27.2 与 Node 24.22.0 LTS 构建。更新 golang.org/x/* 模块及依赖版本：compress v1.20.3、msgp v1.6.5、etcd v3.7.2、fwd v1.2.1 与 cpuid v2.4.1（保留 go-systemd v22.6.0 以支持 NetBSD，保留 tablewriter v0.0.5 以兼容现有 MC API）。
• 构建工具固定为 GoReleaser v2.18.3、golangci-lint v2.15.0 与 govulncheck v1.9.0，重新生成 2.4.2 内嵌前端资产并更新固定摘要的构建容器。

集成说明

由于模块路径保留无 /v2 后缀的 github.com/pgsty/silo-console，Go 消费方通过伪版本 v0.0.0-20261017112417-ef2dd2c41d21 引用。嵌入 Console 的 Server 需同时显式声明 Console 与 MC 替换：

replace github.com/minio/console => github.com/pgsty/silo-console v0.0.0-20261017112417-ef2dd2c41d21
replace github.com/minio/mc => github.com/pgsty/mc v0.0.0-20261017101407-fa3b8bf72458

Console v2.4.2 直接依赖 github.com/pgsty/silo-pkg/v3 v3.14.2（既有密码权限迁移规则见密码权限迁移指南）。注意 go-jose v4.1.6 的 4096 位 RSA JWK 限制仅影响链接了该包的 Server OIDC 路径，独立 Console 二进制未链接 go-jose 与 go-ldap。

发布与验证

全部 44 个发行制品（6 个平台二进制、6 份归档、9 个 Linux 软件包及配套校验清单、SBOM 与签名来源证明）均已核验并与标签源码 ef2dd2c41d21 一致。该提交通过完整 CI 矩阵（权限、SSO、复制、浏览器测试、源码镜像一致性与可复现打包）、漏洞检查、本地 Go race 测试、251 项前端单元测试，以及搭配 Server 20261018 的真实 API 与浏览器分享测试。

公开镜像 docker.io/pgsty/silo-console:v2.4.2（linux/amd64 与 linux/arm64）的多架构索引摘要为：

sha256:4cf47061e0d2f249df3c1cd2a939966ff3c69cc3cf7d10a7b1b39d5c110ae999

发布核验约定 · 组件版本矩阵 · 相对 v2.4.1 的源码差异。

2.6 - mcli 20261018 发布

版本： RELEASE.2026-10-18T00-00-00Z · 软件包版本： 20261018000000.0.0 · 源码： fa3b8bf72458。

本版本作为独立 mcli 客户端及 Server 20261018 与 Console v2.4.2 的配套客户端版本发布（参见 silo-pkg v3.14.2 发布说明）。

更新内容

• 升级至 silo-pkg v3.14.2 与上游 minio-go v7.4.1。SDK 修复取消后的失败分段上传清理、UTC 保留期时间戳格式及 STS 时长透传，并保留既有 CopyObject 内嵌错误处理与校验和逻辑（并行 GET 与 ComposeObject 仍需显式启用）。
• 使用 Go 1.27.2 构建，更新 golang.org/x/* 模块、compress v1.20.3、msgp v1.6.5 与 etcd 客户端 v3.7.2（其中 fwd v1.2.1 修复同时返回数据与错误时的字节丢失及 Skip 偏移；cpuid v2.4.1 修复缓存识别）。
• 通过 silo-pkg 引入 go-jose v4.1.6（修复 RSA JWK 解析 CPU 消耗问题 GHSA-mgcc-cww5-fp2q）与 LDAP v3.4.15。
• 刷新固定摘要的 UBI 9 基础镜像与发行工具链：GoReleaser v2.18.3（含日志脱敏与归档修复）、nFPM v2.48.0、golangci-lint v2.15.0、govulncheck v1.9.0 与 gofumpt v0.12.0。

升级说明

CLI 命令、别名、MC_* 环境变量与本地配置文件格式保持不变（保留 go-systemd v22.6.0 替换以支持 NetBSD 构建，保留 tablewriter v0.0.5 API）。各组件配套关系见组件版本矩阵。

docker run --rm docker.io/pgsty/mc:RELEASE.2026-10-18T00-00-00Z --version

发布与验证

全部 19 个发行制品（Linux/macOS/Windows 的 amd64/arm64 共 6 个归档、6 个 Linux RPM/DEB/APK 软件包、1 份归档校验清单及 6 份软件包校验文件）均已核验，涵盖下载摘要、6 个二进制源码标记、6 个软件包载荷、PGSTY GPG 签名（9592A7BC7A682E7333376E09E7935D8DB9BD8B20）及 11 份 GitHub 构建来源证明（均绑定至 fa3b8bf72458）。

该提交通过 Go 测试、交叉编译、漏洞扫描（无可达或已导入包漏洞；仅保留未导入 OpenPGP 模块公告 GO-2026-5932）及发布流水线检查，并通过针对 SILO fbcb5119782a 的 Go 与 Shell TLS 功能回归测试（制品构建 · Docker 发布）。

公开镜像 docker.io/pgsty/mc:RELEASE.2026-10-18T00-00-00Z（及发布时的 latest，支持 linux/amd64 与 linux/arm64）的多架构清单摘要为：

sha256:6ecdaec70bc5e8cf9d0e9a70c190f3beb1c83f11617ff4333f1fcd71ab1daf18

下载与安装 · 完整变更记录 · 相对 20260916 的源码差异。

2.7 - silo-pkg 3.14.2 发布

发行版： v3.14.2 · 源码： c6835145176f。

github.com/pgsty/silo-pkg/v3 v3.14.2 为 mcli 20261018 与 Console v2.4.2 提供十月依赖基线；后续补丁版 v3.14.3 在此基础上优化了策略判定性能，供 Server 20261018 使用。

变更内容

• 上游 minio-go 升级至 v7.4.1：在调用方取消上下文后仍确保清理失败的分片上传，以 UTC 序列化 Object Lock 保留期时间，原样透传请求的 STS 时长，并支持 Kubernetes 投射服务账号令牌文件（并行 GET 与 ComposeObject 仍需显式启用）。
• go-jose 升级至 v4.1.6：修复解析超大恶意 RSA JWK 时的 CPU 消耗问题（GHSA-mgcc-cww5-fp2q）；同步升级 LDAP v3.4.15、msgp v1.6.5 与 etcd 客户端 v3.7.2。
• golang.org/x/* 升级：x/crypto v0.58.0、x/net v0.61.0、x/sys v0.49.0、x/text v0.43.0。使用 Go 1.27.2 开发与测试，保持模块 go 1.26 最低版本要求及 NetBSD 的 go-systemd v22.6.0 替换。

兼容性与采用方式

require github.com/pgsty/silo-pkg/v3 v3.14.2

公开包签名与密码策略语义保持不变（从 v3.14.0 之前版本升级请参考密码权限迁移说明，各组件依赖对照见组件矩阵）。

行为变更提示：

• go-jose v4.1.6 拒绝超过 4096 位的 RSA JWK，使用该解析器的 OIDC/JWKS 消费方需确认身份提供方密钥长度不超过 4096 位。
• 低于 1 小时的 STS 请求时长现在按原值发送，不再被客户端静默改写，因此超出服务端下限的过短时长会被服务端直接拒绝。

验证

该版本通过 Go 1.27.2 完整 lint 与 race 测试、Go 1.26.9 race 测试、OpenLDAP 集成测试、模块整洁性检查及 govulncheck 扫描（无可达或已导入包漏洞）。

标签源码 CI 记录：Go、LDAP、VulnCheck。

相对 v3.14.1 的变更 · PR #10。

2.8 - SILO 20261015：已替代草稿记录

状态：已被正式版 Server 20261018 替代。 RELEASE.2026-10-15T00-00-00Z 曾于 2026-10-15 13:52:28（UTC+8）短暂公开，随后撤回为 Draft 并由包含完整十月修复栈的 20261018 接替。本页归档该候选版的源码范围与制品验收记录，新部署与升级请直接使用 20261018。

• 历史标签：RELEASE.2026-10-15T00-00-00Z
• 软件包版本：20261015000000.0.0
• 候选源码：7a3ca0f82100cce06289a465f54139da2639f642（相对于 Server 20260916 的完整源码差异）

对象锁修复

• SN-2026-015 — 保留期修改授权（#234）：每次 PutObjectRetention 请求在读取对象状态前，必须携带请求体中的 Object Lock 条件键通过 s3:PutObjectRetention 鉴权。缩短、清除未到期 GOVERNANCE 保留期或改变其模式时，必须同时具备显式 bypass 请求头与 s3:BypassGovernanceRetention 权限（不能绕过基础 s3:PutObjectRetention 的 Deny）。清除保留期按剩余 0 天求值，远期日期计算不再溢出饱和。
• SN-2026-016 — 保护已有版本免受原位覆写（#235）：客户端指定写入 versionId 必须具备可信复制权限（s3:ReplicateObject）。目录 null 版本与持久化分片上传目标在实际覆写前、持有目标写锁时复查锁状态（覆盖升级前创建或从旧暂存状态恢复的分片上传），确保既有 GOVERNANCE、COMPLIANCE 与 Legal Hold 保护生效；锁状态读取失败时拒绝写入。
• 发行前置门禁（#237）：发行构建流水线新增 Object Lock 竞态回归前置检查，覆盖慢请求体目录覆写、预检读取失败、旧分片完成覆写 COMPLIANCE 以及恢复上传 UUID 碰撞。

详见安全公告与修复设计。

20260916 以来的其他改动

组件身份

升级要求

1. 全节点与复制站点升级：升级全部 Server 进程及所有接受 S3 写入的复制站点，避免未修复节点继续放行未授权的保留期修改或原位覆写。
2. 核对策略权限：仅授予 s3:BypassGovernanceRetention 而未授予 s3:PutObjectRetention、或依赖 bypass 绕过保留期条件键的请求将返回 403 AccessDenied。
3. 指定 versionId 写入限制：普通 S3 客户端写入（含 root 签名请求）不得指定目标 versionId；可信复制保留版本 ID，mcli batch replicate 写入 SILO 时目标凭据需具备 s3:ReplicateObject。
4. 锁状态不可读时拒绝覆写：已锁定的目录对象与已有分片目标不可被覆写；若底层锁元数据读取失败，需先恢复存储盘健康再重试。
5. 历史数据排查：升级前已发生的异常保留期变更或覆写不会自动回滚，请结合审计日志核查（从 20260916 之前版本升级时请一并参考九月版升级要求）。

候选制品验收记录

针对候选源码 7a3ca0f82100cce06289a465f54139da2639f642 的流水线与本地核验结果如下：

• 静态制品核验：36 个发行制品、34 份制品来源证明、Linux/macOS/Windows 的 amd64/arm64 共 6 个平台二进制静态身份、6 个 RPM/DEB/APK 安装包载荷与 2 个 RPM 签名全部核验通过（参考历史归档校验和与安装包校验和）。
• macOS arm64 二进制运行验收（110/110 通过）：

（其中 65 次预期拒绝操作均未改变目标对象的任何内容或元数据状态；Windows 与 macOS amd64 为静态身份核验。）

Docker 镜像验收

Docker 发布工作流 38689158028 构建的 linux/amd64 与 linux/arm64 多平台镜像摘要及 OCI 来源证明均核验通过：

四个平台单架构镜像（容器内 /usr/bin/silo 与官方 Linux 归档二进制逐字节一致）均通过 /minio/health/ready 探针与 Object Lock API 套件（196/196 通过，其中 120 次预期拒绝操作均保持对象版本、ETag、保留期、Legal Hold 与版本列表完整不变）：

连同 macOS arm64 原生安装与升级测试，候选制品运行验收合计 306/306 通过。

2.9 - SILO Console 2.4.1 发布

SILO Console v2.4.1 于 2026 年 9 月 16 日发布，源码为 1360e26d976d。 本版接入 pkg v3.14.1 与 mcli 20260916，收紧匿名分享代理，支持多对象流式 ZIP 下载，并提供带签名和构建溯源的发布制品。

共享下载

#52 的修复将匿名代理限制为 配置的 S3 源站上的对象内容 GET 请求，拒绝重定向、系统路径和通过查询参数选择的非下载操作。 公开对象、预签名链接和指定版本下载继续可用。不需要新增一个关闭分享的环境变量。

感谢 Jiri Pejchal（@jiri-pejchal） 报告内部指标暴露问题。 支持的请求形式及反向代理要求见共享下载边界。

密码策略迁移

这个补丁版本包含授权语义变化。 修改密码按钮和会话能力改用 admin:ChangeMyPassword； 创建用户、重置他人密码继续使用 admin:CreateUser。配合对应的 SILO Server， 单独拒绝 CreateUser 不再锁定调用者自己的密码。要保留旧限制，应在升级前于同一个 Deny 语句中拒绝两个动作，保留原资源范围与条件。

更新后的内置 readonly 允许自助修改密码，也不再覆盖另一份策略授予的 CreateUser 权限。 已保存的策略覆盖保留原有语句。请协调升级 Server、Console 与 pkg，并阅读迁移及回滚说明。

下载与浏览器恢复

• 浏览器支持文件写入器时，多选 ZIP 使用背压流式写入，支持取消和重复下载保护；其他浏览器交给原生下载管理器。两条路径都不会在 JavaScript 内存中缓冲整个 ZIP。
• 只有响应提供可靠总长度时才显示百分比。原生下载会明确提示已交接，此后需在浏览器下载管理器中取消。选择超过 5 GiB 或总大小未知时，界面推荐使用 mcli 进行长时间传输。
• 无效路由和渲染异常提供恢复入口，不清空偏好设置；补全中英文字段、图标控件、退出文字和支持键盘操作的提示。

依赖与嵌入

SDK 正确处理 CopyObject HTTP 200 响应内嵌的 S3 错误；JWX 修复自定义 JSON 字段名转义， strfmt 更新 Go 1.27 主机名校验。嵌入前端和第三方署名已按最终依赖重新生成。 go-systemd v22.6.0 与 tablewriter v0.0.5 是保留的兼容性固定版本。

Go 嵌入方通过历史模块路径 github.com/minio/console 的 replacement 选择 github.com/pgsty/silo-console v0.0.0-20260916075814-1360e26d976d。 Go 不继承依赖模块的 replacement，需同时复制标签 README 中显式的 MC replacement。 正式支持的管理对象是配套 SILO 组件；上游 MinIO/MC 兼容性属于尽最大努力。

软件包与验证

本次 GitHub Release 有 44 个附件：二进制及归档、DEB/RPM/APK 软件包、源码、法律声明、SPDX SBOM、校验清单及 Sigstore 签名包。校验清单使用 Cosign 签名，构建溯源记录对应标签和工作流。

独立部署 v2.4.1 请使用 GitHub Release 二进制或 Linux 软件包；docker.io/pgsty/silo-console 的多架构容器镜像自 Console v2.4.2 起恢复公开拉取。Server 内嵌 Console 不受影响。

Linux 软件包保留 minio-console.service、console-user 和 /etc/default/console。 服务状态目录为 /var/lib/silo-console，证书目录改为 /etc/silo-console/certs，停止服务最多等待 90 秒。 已有安装重启前，请按要求迁移证书和权限，或通过 CONSOLE_OPTS 保留旧证书路径。 安装过程保留旧证书与私钥，不会自动重启服务。具体见软件包升级说明。

精确发布源码通过完整 CI 矩阵、 漏洞检查和 发布验证。 本地还验证了 251 项前端单元测试、51 项浏览器测试、嵌入资源逐字节一致性，以及独立和内嵌部署的分享行为。 实际下载的 Darwin/arm64 二进制经过签名校验清单核验，并连接 SILO 测试服务执行了分享验证。

2.10 - silo-pkg 3.14.1 发布

v3.14.1 从 fa657ef4 发布。 这是 github.com/pgsty/silo-pkg/v3 的依赖与工具更新； 相对 v3.14.0 的差异没有修改包的 Go 源码或公开 API。

依赖变化

• JWX 从 v3.2.0 升至 v3.3.0。上游发布说明 将自定义 JSON 字段名编码时缺少转义的问题标识为 GHSA-4cf7-xm37-g63h。可利用性取决于是否接受攻击者控制的自定义 claim 名称； 本包 env 的 JWT 路径仅使用已注册的 claim 名称。
• 上游 minio-go 升至 v7.3.1-0.20260915093545-32e1f32cb176，包含 minio-go #2306：识别 HTTP 200 响应正文中的 S3 CopyObject 错误，避免误报复制成功。
• Testify 升至 v1.12.1，lint 配置采用 gomodguard_v2。 保留 Go 1.26 最低版本、Go 1.27.1 工具链及支持 NetBSD 的 go-systemd replacement。

组件与迁移边界

v3.14.0 的密码策略变化继续生效，本补丁没有回退它。 原先意图同时禁止用户管理与修改自身密码的策略，应按迁移指南 保留 admin:CreateUser 与 admin:ChangeMyPassword 的配对 Deny。

SILO 20260916、mcli 20260916 和 Console 2.4.1 均已选用此包，详见组件版本表。

发布验证记录见上述 release 和 PR #9。

2.11 - SILO 20260916 发布注记

版本日期： 2026-09-16 · 正式发布： 2026-09-17（UTC 2026-09-16） · 标签： RELEASE.2026-09-16T00-00-00Z · 软件包版本： 20260916000000.0.0。安装入口见下载页。

源码范围为已发布提交 9b11dc9469e6 到本版 2a4d51406b7e，共 210 个提交，其中 140 个非合并提交。本文覆盖该范围内的最终行为，包含 #214 之后的列表 quorum、版本 purge 和迁移标签修复。

本版重点

• 更完整的请求认证边界： 关闭普通签名与预签名请求的未签名操作头缺口，校验预签名正文摘要，使签名年龄及载荷哈希策略使用可信输入。
• 可持久恢复的 IAM 撤销： 保留删除版本、父身份撤销边界与成员授权时间，防止延迟事件、重建同名身份和重启恢复重新激活旧授权。
• 多池操作针对同一个逻辑对象： 条件 PUT、分片完成、条件 DELETE、指定版本删除及元数据协调使用一致的对象选择和锁边界。
• 池迁移保留标签： rebalance 和 decommission 的普通对象及分片迁移恢复完整标签写入，保留原修订和有序清空状态。
• 修复加密及联邦复制： 保留 SSE-C 原始副本、明文分段大小、独立 Object Lock/标签修订，以及远端实际写入的校验和、版本和时间。
• 复制和配置最终状态更可靠： 修复标签删除复活、删除标记 purge/MRF、resync 计数与取消、桶配置来源时间和删除状态收敛。
• 可选的严格分片发现： 新增持久化扫描、全局分页和只读预检；默认仍为 legacy，容量和迟到创建写入的限制明确保留。
• 更新整套管理工具： 内嵌 Console 2.4.1，捆绑 mcli 20260916，采用 pkg 3.14.1；补齐浏览分页、流式 ZIP、错误退出码和策略正确性。
• 两项必须提前安排的升级变化： 密码权限拆分会改变已有策略的含义；持久 IAM 撤销要求协调升级和完整后端备份。

版本与组件

本版的 Console 和 MC replacement 分别为 v0.0.0-20260916075814-1360e26d976d、v0.0.0-20260916070421-e952aa78f10a。Go 不继承依赖模块的 replacement，因此 Server 显式选择两者。pkg 直接使用 PGSTY 模块路径；Server、Console、MC 保留现有历史模块身份和协议名称。minio-go/v7 继续使用经过核验的上游版本。

正式维护和发布验收面向 SILO + Console + mcli + silo-pkg；与未修改的上游 MinIO/MC 保持尽最大努力兼容。

安全与授权

本轮包含四个本地安全编号；SN- 是项目台账编号，不是 CVE。完整说明见签名头边界及九月安全说明。

签名配套修复还包括：消除重复复制源头的取值歧义；从签名日期计算 s3:signatureAge，移除请求头中的临时缓存值；统一预签名 query/header 的有效载荷哈希优先级；将 PutObjectTagging 的服务端合成头放到验签之后、授权之前。X-Amz-Content-Sha256 仍可不列入 SignedHeaders，但其有效值和正文校验必须一致；明确签入的 UNSIGNED-PAYLOAD 保留原含义。

streaming SigV4 seed 的未签名操作头仍在此检查范围之外。未签名头拒绝继续返回 400 AccessDenied。Console 分享修复未新增全局关闭分享的环境变量，继续执行 S3 授权检查。

密码权限拆分：兼容性变更

Server #175、pkg #6 和 Console #51 将自助修改密码与用户管理分开：

• 内置用户修改自身密码检查 admin:ChangeMyPassword；无显式 Deny 时允许自助操作。
• 创建用户、重置他人密码仍要求 admin:CreateUser；root、STS、服务账号原有身份限制继续生效。
• 单独 Deny admin:CreateUser 不再锁住调用者自己的密码；原有 Deny admin:ChangeMyPassword 开始实际约束这一入口。
• 更新的内置 readonly 不再以 CreateUser Deny 覆盖其他策略给予的用户管理权限，并支持独立的 consolereadonly 能力；已有保存的策略覆盖不会自动重写。

若要保留旧的组合限制，升级前就在同一条 Deny 语句中列出两个 action，保留原 Resource 和 Condition。 回滚旧 Server 时也保留这对 Deny，因为旧实现不能单独执行密码专用 Deny。详见密码权限迁移。

共享策略实现

pkg #4 修复 NotResource 未进入去重哈希、不同字符串条件集合表示碰撞而丢失 Deny 的问题；直接构造的 policy 也能在建立索引前报告 Deny。多星号通配匹配移除指数级递归，保留原有字节匹配与 MatchSimple 边界语义。

因此，过去依赖错误丢弃 Deny 才成功的请求可能开始被拒绝。若错误语句已经从保存的 JSON 中消失，升级无法还原，必须与原策略源比对后重新提交。

IAM 复制、撤销与恢复

删除版本保留在原 IAM 配置路径，覆盖用户、服务账号、组、策略及各类策略映射；普通列表与授权隐藏删除记录。对象存储和 etcd 后端均串行化版本比较和写入，接收端保存来源时间，相同时间删除胜过活记录。

• 延迟的同后端删除通知重新读取已提交状态，避免删除随后重建的身份。
• 同名父身份重建保留 RevokedBefore；新服务账号和内置 STS 携带签名的 siloParentRevocation 边界。旧子凭据即使被重放或更新，也不能重新获得效力。
• 每个组成员保留自己的授权时间，编辑另一成员或组状态不会顺便给全部成员重新授权。
• 较新的服务账号快照可替换同 key 的旧副本，保留 secret、disabled、绝对过期时间和撤销边界；身份类型冲突报错，过期快照不能延长旧凭据寿命。
• Healing 在失去和重新取得领导权后能恢复；保留已确认版本并以有界批次重试。自然过期的普通 STS 不被无条件转成永久删除记录，服务账号 key 的复用仍保留版本历史。
• 新增 IAM 撤销数量、healing 失败数、耗时和最近成功时间指标，见设计与指标。

跨站点撤销异步传播。父身份删除先于后续清理提交；若后续清理返回 HTTP 500，父身份撤销实际已经生效。墓碑没有 TTL 或自动压缩；存储和启动成本随保留历史增长。删除后组成员的独立增删、同时间活记录冲突、任意时钟偏差和跨站点逐 token 撤销仍有明确边界。

S3 条件操作与多池一致性

跨池协调层先在共享命名空间锁内选择逻辑对象，再判断条件或合并同版本状态。正在退役、排空的池也参与相关状态检查；保留期、legal hold、标签分别按自己的修订排序，不能用对象修改时间代替所有字段的版本。

可用性取舍： 任一相关池元数据无法确认时，条件 PUT/分片完成及协调删除可能失败，即使另一池仍可提供 GET/HEAD。读仲裁不足返回 503；恢复可读性后重试。清理失败可能发生在部分磁盘修改之后，没有分布式回滚保证。出站删除复制未完成时会保留等待 purge 的版本。

普通条件 PUT 带目标 versionId 时仍比较当前对象，同时保留指定写入版本。该修复不清理其他池旧副本、不撤销历史错误覆盖，也不新增全局时钟顺序保证。#190 的分片修复与 #207 的普通 PUT 修复是两个独立问题。

未支持的边界： 批量 DeleteObjects 的 XML <ETag> 仍不提供条件保护；空 If-Match 按普通删除处理，内部递归前缀删除不走对象条件。尚无 s3:if-match 策略键，也没有额外的 GetObject 权限检查。需要条件保护时使用支持的单对象路径。详见条件删除与多池一致性。

池迁移保留对象标签

fced8630365f 修复 rebalance/decommission 迁移时丢失对象标签的问题：读取表示把标签放在 ObjectInfo.UserTags，迁移过去直接转交 UserDefined，可能漏掉目标写入所需的规范标签字段。

普通 PUT 与 multipart 初始化四个入口现在从独立的 metadata 副本重建标签字段，保留标签原修订，包括缺失、空值和已有的有序清空状态；迁移不生成新的标签修订，也不修改 reader 的 map。写入与分片完成继续使用现有锁内重读协调，避免旧 reader 越过后来的标签更新或清空。

此补丁不自动恢复历史已丢标签；请单独核对过去迁移过的对象及依赖标签的策略和生命周期规则。

null 版本列表 quorum

8d06424b1 修复新版本少数派掩盖旧版本多数派的列表选择问题。只有原选择未达到 quorum、每条非空磁盘流恰好只有一个普通 null 版本且纠删布局相同时，才按 header 重新计数；不扩大到混合版本历史。

仍有限制： #218 记录并发覆盖期间逐节点重启时，HTTP 200 列表仍可能遗漏可读取对象。不要用该阶段的列表驱动会删除目标多余对象的同步工具；集群稳定后重新列举。

加密对象、校验和与属性

• 原始 SSE-C 副本正确落盘： 已授权复制携带的密文按原样保存，避免目标默认加密或压缩再次变换，造成双重加密或不可读对象（#109、#122）。
• 保存明文分段大小： SSE-C multipart 副本记录逻辑长度，修复 part-number/range 读取、覆盖后对象大小和属性结果（#119、#124）。
• 排除 SSE-C 压缩： 普通 PUT、多段初始化、COPY、Snowball 不再新建压缩 SSE-C 对象，避免解密得到压缩流而非原文；SSE-S3/SSE-KMS 保留相应压缩选项（#118、#126）。
• 支持重传修复： 已存在或不可解码的 SSE-C 副本通过对象重传更新，不误用普通 metadata COPY；保留目标较新的保留期与 legal hold（#120、#134）。
• 密钥轮换遵守显式 checksum： 请求算法时执行必要的完整重写，包含与现有算法相同的请求；多段源可能变为单段目标，ETag 可能变化（#113、#123）。
• 属性返回逻辑结果： GetObjectAttributes 对压缩/加密分段返回明文尺寸，稀疏 part number 的末页正确结束（#114、#115、#128）。
• 不可读对象不冒充成功： 解密或存储完整性失败返回 500，不再以 206 被客户端当作有效读取（#110、#121）。
• 兼容 chunked checksum： 非 trailer 模式的 chunked PUT 即使声明 x-amz-trailer，实际放在普通 header 中的 checksum 仍被采用与验证（#107、#143）。

这些是预防新错误和提供受支持修复路径，不是自动重写历史加密数据。历史压缩 SSE-C、错分段尺寸及不可读副本须保留密钥和精确版本身份，另行读取验证。SSE-C 完整性说明列出恢复边界。

联邦 CopyObject

本节针对旧 etcd 桶联邦的远端转发，区别于桶/站点复制。累计修复来自 #157、#159、#163、#172、#177、#179。

对应问题：#99、#100、#158、#166–#171。远端已提交写入之后仍可能因响应校验失败返回错误；版本化重试前先核对目标实际版本。详见联邦复制契约。

Object Lock、标签和复制恢复

保留与标签独立排序

• 只有 legal hold 的普通写入不再跳过桶默认 retention；ON/OFF 都不能替代保留期选择，显式时间精度保留（#165、#177）。
• 空值与只有时间戳的 retention/legal-hold 删除参与顺序比较，不抹掉更晚的目标状态，也不导致无穷重发（#111、#117、#129、#131）。
• 多池副本写入选择跨池权威 Object Lock 状态，关闭原先只在单个 erasure set 内成立的边界（#133、#178）。
• 副本协调时将标签值与修订一起带回，避免现有标签被空值覆盖；SSE-KMS metadata COPY、SSE-C 轮换保留标签时间；本地 PUT/DELETE tagging 单调推进修订，空标签作为有序删除抵御延迟重放（#189、#193、#196）。

复制双方须更新才能尊重空标签墓碑。带已记录标签修订的对象在显式 resync/heal 时每对象增加一次 metadata COPY；目标按桶默认 KMS 加密时可能重写数据。带标签过滤的复制规则仍按删除后的空标签决定目标资格。历史缺失或畸形修订不会被自动重建。详见Object Lock 排序和复制标签排序。

删除标记、MRF 与 resync

• 单对象删除标记 purge 正确分类，并在 worker、scanner/heal 和持久 MRF 恢复中保留标记身份及重试状态；只在 bucket、key、version、修改时间与任务匹配时接受相应 405 标记响应。审计状态由 COMPLETE 统一为 COMPLETED（#153、#162、#196）。
• 有界 MRF 队列的丢弃通过管理信息、指标与去重日志可见，并统一对象/删除 worker 分配；这不把有界队列变成永不丢弃的无限队列（#152）。
• resync 在发布 Completed 前应用最后的计数；以实际复制结果而非“目标已存在”判断成功（#136、#139）。
• 按正在同步的目标 ARN 派发；每个 resync ID 使用独立取消上下文，阻塞派发、walker 和 worker 能收尾，旧任务不能覆盖新终态（#141、#137）。

精确版本 purge 与排队创建

eb4f5e5b3 使纯版本 purge 不再向原本没有标记的磁盘创建标记；不存在版本的重试须由写 quorum 多数确认缺失，汇总已删除和可靠缺失的回复。接收端跨池解析指定版本，标记 healing 保留复制和 purge 元数据。

254b19ac0 在复制锁内重新读取排队的标记创建任务：版本已不存在、已非标记或正在 purge 时丢弃旧任务；读结果不能确认时通过 MRF 重试。该检查覆盖 DELETE handler、GET/HEAD/LIST heal、scanner 和 MRF 排队的任务。

358ab38fb 只把实际存储的标记报告为 delete marker，避免将等待 purge 的数据版本错误返回为 x-amz-delete-marker: true 并产生错误事件。

仍有限制： 已发出的创建请求、其他站点的重放，以及多数确认 purge 后崩溃留下的少数磁盘残留，仍由 #217 跟踪。该修复不构成接收端持久删除屏障。

副本元数据正常化

普通元数据提取之后只恢复六项复制专用字段，不再把传输用 aws-chunked 重新持久化为对象 Content-Encoding；可信 Snowball 条目也不继承外层归档的普通对象元数据（#185、#194）。

上述变更不会扫描或重写历史对象，不会自动恢复丢失标签、Object Lock 历史或所有未收敛 purge。请使用只读审计工具与手册处理精确版本、混合 Content-Encoding、歧义分类和受控恢复，不要直接做批量 self-COPY。

桶配置、缓存与启动

PR #180 完成 #77 的来源状态收敛：Policy、Tags、SSE、Quota、Versioning、Object Lock 的读取、比较、修改和保存处于同一 metadata.lock 中。peer 保存来源时间，本地更新在已有时间之后单调推进；同时间删除优先，其余冲突用稳定内容键裁决。

• 专用事件、bulk、import、初次同步和 heal 使用一致规则，省略字段保持既有设置不变；Versioning/Object Lock 的空事件仍不提供删除能力。
• Policy JSON 规范化，已接受的 NotAction / NotResource 策略能正确 GET/export；Statement/集合顺序可能变化，授权语义不因此改变。
• 空 Policy 继续按删除处理；零 Quota 保留有值文档，容量不受限制，不能把它悄悄转成不同的删除状态。
• 旧桶缺少 Created 时从物理信息恢复并落盘；接管不把默认空状态误认作删除，未知/无效/不可达来源有有界诊断。
• MINIO_SITE_REPLICATION_METADATA_TOMBSTONES 默认 off。升级所有参与站点后才统一设为 on 并重启，使 Tags/SSE/Quota 的缺省载荷删除时间对 heal/初次同步可见。关闭期间遗漏删除的收敛仍有边界。

被旧接收时间污染的历史配置不会自动重写，且新增的持久 IAM 状态不支持滚动降级。桶配置收敛说明给出更细的恢复与取舍。

同一版本还修复：桶删除/更新/生命周期读取与缓存发布的剩余竞态；移除把“各字段最大时间”误当整记录版本的 reload guard，使等最大时间下的新字段仍能更新；桶 metadata 导入导出保留 per-bucket CORS（#105、#112、#127、#156、#164）。

#116 补全启动就绪窗口说明及 Linux 重启验证：除检查健康探针外，还应在每个协调节点使用签名 PUT/GET 请求验证数据路径就绪。OIDC 修复见下节。

分片上传发现、分页与取消

PR #198 增加持久化发现，#213 随后恢复保守的默认及回滚兼容性。20260916 的最终默认是 legacy。（SILO 20261018 4733e1423 随后退役了 MINIO_API_MULTIPART_LISTING=strict，仅保留 legacy 缓存／精确 key 列表作为公开模式；参见最新决策。）

新 writer 在现有 quorum 写入的 xl.meta 中保存保留的 bucket/key 身份，完成上传时删除这些临时字段；没有二级索引或目录格式迁移。两种模式共用的 maxUploadsList 请求上限从 10,000 降至 1,000。它限制传入的页长参数；legacy 缓存路径仍会因忽略分页而返回更多记录。

只通过进程环境 MINIO_API_MULTIPART_LISTING=strict 启用并重启；不支持 mcli admin config set 动态设置。非法值诊断后回落 legacy，不丢弃其他 API 设置。启用前升级所有 writer、排空旧上传、执行需要 admin:StorageInfo 的只读 GET /minio/admin/v3/multipart-preflight，再验证部署容量。旧上传缺失身份可能阻断 strict 下其他桶的列表。

每进程最多两个扫描；每扫描 16 个身份 worker、4 个 metadata worker、30 秒 context，合计目录条目预算 100,000（按跨盘目录条目累计，而非 100,000 个唯一上传）。每页重新扫描持久状态，预算耗尽或不确定覆盖返回 503，而非成功的局部页。临时 10,000 上传、四 APFS 卷试验的一页耗时 18.7 秒，未达到暂定五秒目标。

两种模式都修复错 bucket/key 的 Abort 误清有效缓存，以及解锁后 peer 通知失效的问题。HTTP 层不存在上传仍返回幂等 204。迟到的创建写入仍可能在取消成功后恢复上传，未加入持久创建屏障。 因此 #79 保持开放。详见启用及回滚契约。

Console 2.4.1 的累计改进

除分享代理和密码权限修复，本次内嵌选择还包含从 20260903 之后积累的浏览器、管理 API 和交付改进：

• 对象游标分页： 使用 ListObjectsV2，支持每页 50/100/250/500/1000 项；排序、过滤、选择明确限定当前页，不为总数扫描整个桶；翻页失败保留当前列表，取消后释放列举 worker，rewind 明示行数和时间范围；空或 null versioning 响应不再使列表崩溃。
• 精确操作对象身份： 删除保留 bucket/key/version，目录删除限制在带尾斜线的前缀内；生命周期编辑保留 current/noncurrent、按日期和未展示字段，正确读取旧 prefix 并移除过期 filter 表示；删除复制规则保留共享目标，最后一条规则使用配置删除 API。Governance bypass 对有权用户显式提供、默认关闭，包括仅对象级设置保留期的情况。
• 权限和会话： Create Bucket 按 s3:CreateBucket 显示；后台请求传输失败不无条件注销；Watch 参数正确 URL 编码，Inspect 保留结构化错误、不重复读取响应体。
• 嵌入兼容： 修复回环 TLS 登录；只对 Server 明确初始化的 TCP loopback peer 应用嵌入代理信任，独立默认仍为不信任；恢复四个 WebSocket 连接限制配置，避免所有公共浏览被错误压在单源八连接内（Server #108、#147、#148）。
• 流式 ZIP： 有文件 writer 的浏览器以背压写入并支持取消；其余交给原生下载管理器，不在 JavaScript 内存中缓存整个归档。原生交接后的取消由浏览器负责；只在可靠长度可用时显示百分比，大于 5 GiB 或未知大小推荐 mcli。
• 恢复、翻译与无障碍： 畸形路由、持久偏好和渲染异常提供恢复入口，补齐中英文字段、图标控件名称、退出文字和键盘提示；共享下拉框修复快速点击/触摸选到旧悬停项，禁用项不再误选其他值。
• 独立软件包： 增强可复现构建、固定工具及浏览器依赖、SBOM/签名/来源验证。systemd 保留 minio-console.service、console-user、/etc/default/console；证书目录改为 /etc/silo-console/certs，需按指南处理旧证书和权限，升级不自动重启服务。

来源：Console #47、#50、#57、2.4.1 注记。

mcli 20260916 的累计改进

镜像捆绑的新客户端包含 20260913 与 20260916 两批变化：

• pipe 使用已应用的全局 quiet/JSON 设置，重定向输出不混入进度条；空输入保留显式 checksum，非空输入持续流式处理。MC_* 布尔量接受 on/off/enabled/disabled。
• S3 Select sql、传输、mirror 权限失败、legalhold、递归 retention 部分失败及 mv 源删除失败返回非零；mv 等待删除结果，成功复制的目标不回滚。
• mirror 的逐对象权限错误不会阻止后续对象；有限任务有失败返回 1，失败任务不输出普通成功结尾。显式 summary 的 JSON 标为 failure，极短传输速度保持有限数值；列举/监听的取消重试策略仍有原有边界。
• mirror --remove --watch 不因源历史版本删除而误删目标；管理重启 dry run 不退化成真正重启，非 TTY 结果可靠。
• 空 retention 时长、无效 find --regex 正常报错，不再 panic；JSON usage error 不混入不合法格式。
• SDK 识别 HTTP 200 内嵌的 CopyObject 错误，避免 mv 误认复制成功后删除源。此修复适用于客户端选用 CopyObject 的路径（通常小于 64 MiB 或显式 --disable-multipart），默认大对象路径走 ComposeObject。

脚本应检查最终退出码，而非开始时的 success 消息或进度字节。--skip-errors 不把已经发生的失败恢复成退出码 0；部分 retention JSON 错误文字可能为空。命令、别名、MC_*、配置格式与包名保持兼容。

HTTP、TLS 与可观测性

• 绝对请求头期限： #196 使 --read-header-timeout / MINIO_READ_HEADER_TIMEOUT 真正进入 HTTP Server，连接包装器不再让持续小读无限延长 HTTP/1 请求头期限。默认 30 秒；正文保留滚动空闲超时。缩短值也收紧 TLS 握手读取窗口；HTTP/2 保留其独立行为，TLS 写入侧和 handler CPU/存储等待不因此获得新总期限。负值关闭头部专用上限，不推荐使用。设计说明回应 #183。
• 恢复 Go TLS 默认值： 移除 Server 八处显式曲线覆盖，使 listener、节点、身份提供方、复制和 etcd transport 尊重 Go 1.27 的默认密钥交换及相应 GODEBUG 控制；证书、主机名验证保持严格（#164）。这会改变 SILO 在线上发送与接受的内容： 不设 GODEBUG 时，提供的 group 列表变为 Go 当前默认值，额外包含 SecP256r1MLKEM768 与 SecP384r1MLKEM1024；设了 GODEBUG=tlsmlkem=0 时，该开关现在真正生效——作用于整个进程，出站与入站监听器同样适用。#154 已关闭，但报告人 2026-09-17 在本版本上的复测仍然失败；discovery/JWKS 总期限仍为独立事项。参见 TLS/OIDC 说明 与《写死 TLS 参数与握手兼容性》。
• CPU 指标竞态： loadCPUMetrics 对外层和嵌套 map 加读锁，防止 Prometheus 抓取与资源更新并发导致整个进程退出。修复已随 #214 进入 main；独立 #215 以替代方式关闭，问题 #210 也已关闭。
• 配额和日志指标： 使用生效的 BucketQuota 字段；AddSystemTarget 幂等，串行化 logger 初始化和 console target 发布，防止日志订阅后重复 collector 破坏 /logger/webhook 指标（#106、#150、#132、#151）。

依赖、构建与工程维护

• amqp091-go 从 1.10.0 升至 1.14.0，包含恶意 AMQP frame 过量分配修复；SILO 中可达性需要配置 AMQP 通知目标（#176、#177）。
• JWX 3.3.0 修复自定义 JSON 字段名转义；strfmt 0.27.2 修复 Go 1.27 主机名验证；LZ4 4.1.30 修复 reader、部分读取及并发行为，本版增加 Snowball/S3 Select 集成回归。
• 上游 SDK 累计包含可配置上传限制、streaming Content-Type 签名、RDMA 使用调用方 TLS 信任、列表 checksum 与可选 restore status 一致性，以及前述 HTTP-200 CopyObject 错误处理。见上游采纳记录。Console 同时更新 React Router 7.18.4，并保留 js-yaml 与 smol-toml 的拒绝服务修复及重建后的嵌入资源。
• Go x/* 依赖刷新；保持 Go 1.27.1、NetBSD 所需的 go-systemd 22.6.0 replacement 和现有 tablewriter 兼容选择。
• 容器基础镜像 digest 更新，双 Linux 架构从校验源码构建静态 curl 8.22.0；客户端安装器和镜像固定 mcli 20260916 的实际已发布归档及 SHA-256。
• 本版固定 GoReleaser 2.18.1 与 Action v7.2.3 的完整 commit；依赖文件改动也触发 Test Release Pipeline。tag 源码附带 Helm Chart 7.0.3 和新 Server/mcli 默认标签；没有单独的 Chart 发布。
• 修复条件 PUT 与标签复制测试夹具竞态，恢复集成脚本有效凭据；将相应 CPU、标签、multipart 和 S3 Select race 回归纳入 CI。
• 持续校正 rebrand guard，明确 AGPL-3.0-or-later、DCO 和无 CLA 的贡献规则，保留实际人类贡献记录；README 仓库卡片增加每日更新流程。
• 正式产品、升级、安全和设计文档集中在本站；源码仓库保留入口、必要兼容文档和测试材料。迁走临时调查与旧安全工作资料，历史证据以固定提交链接保留。

9 月 4 日的 Helm 正式镜像标签校正、mcli 归档 pin 和容器恢复发布完成了上一版的交付。

撤回的实验功能

GET 访问频率驱动的池间 ILM 分层 #60 于本周期合入，随后由 #188 移除。它从未进入正式 Server 20260903，也不属于本版的新增功能。 移除 tracker、mover、scanner hook、专用配置/XML action 和指标；十个旧 ILM 键兼容接受但忽略，读取 v8/v9 usage cache 并写回不带退役字段的 v8。

使用过中间开发构建的部署应移除 access-only 规则，编辑混合规则时保留普通动作。普通过期、远端 tier、rebalance、decommission 继续存在；独立的多池 Object Lock、条件删除、写入协调和共享远端引用保护保留。迁移说明解释具体范围。

升级与恢复要求

1. 固定最终组件和制品。 实际 Server、Console、mcli、包、镜像和 Chart 应逐一核验身份。官方镜像名称统一使用 docker.io/pgsty/silo、docker.io/pgsty/mc 和 docker.io/pgsty/silo-console。
2. 提前迁移密码策略并核对原始 Deny。 要维持旧组合限制，在同一 Deny 中保留 CreateUser 与 ChangeMyPassword。对曾丢失语句的策略从原始来源恢复。
3. 安排协调维护窗口。 暂停 IAM 修改，隔离未知离线站点；升级所有参与节点/站点，包括共享 IAM 后端但未启用站点复制的节点。不支持同后端新旧混跑或滚动降级。
4. 保存完整恢复点。 备份 IAM 后端及加密材料；mcli admin cluster iam export 只包含活记录，不能备份删除历史。恢复前停止相关进程，防止继续使用旧缓存/peer 确认。
5. 逐入口验证身份与数据。 旧撤销凭据应拒绝，新用户、服务账号和新签发 STS 应在每个节点有效；验证签名 PUT/GET、对象字节、版本、标签、保留期和复制收敛后再恢复业务流量。
6. 回滚须调和备份后的撤销。 恢复旧快照会丢失后续撤销；在每个恢复站点逐一调和并检查全部端点，必要时改用不同名称的新身份、重新签发凭据。不承诺恢复前 STS 会话连续性。禁止在线删除 tombstone 或只转换活记录来强行启动旧版。
7. 分别启用两个可选行为。 桶配置 tombstone export 只有全员升级后才打开；strict multipart 还要求所有 writer 更新、旧上传排空、预检和容量验证。正常升级可继续使用默认 legacy。
8. 处理开发版本残留。 若运行过写入共享 api multipart_listing 的中间构建，备份后用 mcli admin config reset ALIAS api multipart_listing 定向清除，保留其他 API 设置；不要重置整个子系统，也不要重放含旧键的历史。使用过访问频率分层的部署按撤回指南清理。
9. 检查出站链路上的 TLS 检查设备。 握手内容在 20260903 随 Go 1.27 工具链变过一次，本次再次变化。SSL 检查 NGFW、SASE 网关、IDS/IPS，或按 JA3/JA4 客户端指纹做白名单的环境，都可能让身份提供方、webhook、远端分层或复制连接以 connection reset by peer 被重置，而同一容器里的 curl 却正常。升级后请验证 OIDC discovery 与 JWKS、审计与通知目标、远端分层和复制端点。处置办法与代价见《写死 TLS 参数与握手兼容性》。
10. 单独审计历史对象。 盘点不可读 SSE-C、错误分段尺寸、标签/锁状态、aws-chunked 污染、错误覆盖和待 purge 版本。经批准的恢复清单应在副本环境验证。

操作依据：IAM 升级与恢复、历史副本审计、密码迁移、分片列表契约。虽然对象数据与纠删码布局未变，但新增的持久 IAM 状态不支持滚动降级回旧版 Server 二进制。

已知限制与未完成事项

验证与发布状态

发布源码 2a4d51406b7e 的 Go CI 和 Test Release Pipeline 已通过。Release 构建和 Finalize 已完成。GitHub Release 提供 36 个资产，包括六平台归档、Linux 软件包、SBOM、校验和与证明材料。

Console v2.4.1、mcli 20260916 和 pkg v3.14.1 已分别发布。2026-09-17 复核时，独立 docker.io/pgsty/silo-console 的匿名 token 请求返回 HTTP 401，尚不能确认公开拉取；可使用 Console 的 GitHub 二进制或软件包。Server 内嵌 Console 的源码选择不受此独立镜像分发状态影响。

问题索引与贡献

本版已修复或在明确范围内完成的问题组为：条件操作 #10/#133/#144/#199；联邦复制 #99/#100/#158/#165–#171；桶元数据 #77/#105/#112；加密与属性 #107/#109–#115/#117–#120；嵌入 Console #108/#147/#148；复制调度恢复 #136/#137/#139/#141/#152/#153/#185；运行与指标 #106/#116/#150/#154/#176/#183/#210。池迁移标签补丁以直接 main 提交列示；#79 保持部分实现而非关闭。编号详情和限制见上文各节链接。

感谢报告、补丁与复核参与者，尤其是 @mrjavadseydi（配额、分片列表与分层探索）、@nikitapogromsky（logger 幂等）、@Aeirx（联邦 legal hold）、@magicxor（条件 DELETE 早期方案）、@julienlau（purge/MRF）、@chodorenko（复制编码）、@orenyomtov（签名头报告）、@jiri-pejchal（Console 分享）、@AEGEGE（HTTP 报告）、@aschyolkin（CPU 竞态），以及 @vampywiz17、@kh0mka 等复现和反馈参与者。

PR #12、#125、#155、#184、#187、#195 等原始提交已由后续实现替代。完整署名见贡献记录。

上一正式版 · 本版源码差异 · 组件矩阵

2.12 - mcli 20260916 发布

版本： RELEASE.2026-09-16T00-00-00Z · 软件包： 20260916000000.0.0 · 源码： e952aa78f10a。

相对 20260913 的变化

• 接入 silo-pkg v3.14.1、上游 minio-go v7.3.1-0.20260915093545-32e1f32cb176 和 JWX v3.3.0。CopyObject 会重试并报告 HTTP 200 响应内嵌的 S3 错误，避免复制失败后授权 mv 删除源对象；JWX 正确转义输出 JSON 的字段名。
• mirror 报告权限失败，包括源不可读、目标写入拒绝及本地目标删除失败。后续对象继续处理，有限任务有失败就返回 1；这些逐对象权限错误不要求 --skip-errors，也不会在 watch 模式中重启整个扫描。
• 列举与监听失败保留原有取消重试路径。持续拒绝列举权限仍可能导致反复重扫，本次没有重写该重试策略。
• 失败的 mirror 不再输出普通成功结束统计；显式 --summary 仍输出统计，JSON 使用 status: failure，文本错误诊断仍位于 stderr。同一时钟刻度内完成的极短传输不再产生无穷大的 JSON 速度值。
• legalhold set/clear、递归 retention 部分失败、mv 源删除失败都返回非零。mv 等待删除结果，已成功复制的对象不回滚；retention 每个失败对象只输出一次诊断，避免重复或误导提示。
• 空 retention 时长与非法 find --regex 表达式正常报错，不再 panic。

脚本兼容性与升级

上述曾返回 0 的失败路径现在返回 1。 请检查最终退出码与错误记录。mv 删除失败可能使源和已成功复制的目标同时存在，重试前应核对两端状态。

配置格式、别名、MC_* 变量、命令与包命名保持不变。pkg v3.14.1 保留 v3.14.0 引入的密码权限语义。见组件版本矩阵与密码权限迁移。

正式支持和管理接口验收以 SILO 为目标；对原厂 MinIO 与其他 S3 服务保持尽最大努力的兼容。

交付与验证

本次发布包含 19 个资产：Linux/macOS/Windows 的 amd64/arm64 共六个归档，Linux 两架构的 RPM/DEB/APK 共六个包，一个归档校验清单，以及六个包校验文件。归档、清单与 DEB/APK 通过 Sigstore 构建证明绑定到签名 tag 与精确源码；RPM 携带 PGSTY GPG 签名（9592A7BC7A682E7333376E09E7935D8DB9BD8B20）。

最终发布提交通过 Linux/macOS/Windows race 测试、Linux 386 测试、交叉编译、漏洞扫描和发布打包流水线。发布前还验收了已发布 SILO 20260903 与修复后的 Server 源码 3c26a8b0b5bd、Object Lock 与权限失败、CopyObject 故障注入及双架构 RPM/DEB/APK 安装升级。扫描未发现可达漏洞或已导入包漏洞，仍保留未使用 OpenPGP 代码的模块级提示。

CI: VulnCheck · Test Release Pipeline · Crosscompile · Go · Release · Docker

docker.io/pgsty/mc 版本标签和 latest 对应同一经过验证的 Linux amd64/arm64 manifest：

sha256:cfc83108c3abb371f8fb84d99c1fdc88f8c237e022409b0081fb7c0a3be634dd

下载与安装 · 客户端兼容性 · 完整源码差异。

这项 HTTP-200 CopyObject 修复适用于 mcli 选择单次 CopyObject 的路径：对象小于 64 MiB，或显式指定 --disable-multipart。64 MiB 以上的复制默认走 ComposeObject 路径。

JWX 的具体范围及 GHSA-4cf7-xm37-g63h 见 pkg 3.14.1。--json mirror 失败后若未指定 --summary，不会补一条尾部统计记录；--skip-errors 也不会把已经发生的失败恢复成退出码 0。部分 retention JSON 失败记录只有 status: failure，错误对象可能序列化为 {}，消费方不能强制要求人类错误文字存在。

2.13 - mcli 20260913 发布

版本： RELEASE.2026-09-13T00-00-00Z · 软件包： 20260913000000.0.0 · 源码： 4f609a4d。

相对 20260903 的变化

• mirror --remove --watch 保留目标端历史版本。
• 服务重启的 dry run 只显示计划，不执行重启；明确非交互环境行为。
• 传输与 S3 Select 出错时返回失败；空上传遵守显式校验和参数；quiet 模式下仍输出 pipe JSON。
• 布尔环境变量接受 on/off，修复跨平台 CLI/JSON 行为。
• 使用 pkg v3.14.0 与上游 SDK v7.3.1-0.20260910142817-60bd07042d49，刷新 Go x/*、UBI 依赖，保留 Go 1.27.1。NetBSD 继续固定 go-systemd v22.6.0。

保留 pkg v3.13.3 引入的 Deny/NotResource 与有界通配匹配修复。 正确保留的 Deny 可能拒绝曾依赖丢失语句而成功的请求；已经丢失的语句仍需从原始策略恢复。

新 pkg 还改变密码能力。协调升级 Server 前请阅读密码策略迁移。 配套密码界面已随 Console v2.4.1 发布，协调升级见组件版本矩阵。

制品与验证

不可变发布包含 19 个附件：Linux、macOS、Windows 的 amd64/arm64 共六个归档包， 两种 Linux 架构的 RPM/DEB/APK，以及校验清单和软件包校验文件。 归档与校验清单已核验构建证明，RPM 携带 PGSTY GPG 签名；macOS arm64 原生执行版本输出与 Go 构建信息已核对。

docker.io/pgsty/mc 的发行标签与 latest 指向同一份已验证的 amd64/arm64 manifest：

sha256:aa5cc1401b3e1ab482d215d5717e9e69b4f14970a3656f330ed20a549fe19020

容器发布流程 已完成，两种架构镜像均经拉取和版本检查。 打标签前 Go、交叉编译、漏洞与 Test Release 门槛均通过。 扫描没有发现可达或已导入的易受攻击包；未使用的 OpenPGP 仍有模块级 GO-2026-5932 告警。 与上游 MinIO、其他 S3 实现的兼容属于尽力保留；正式管理集成目标是 SILO。

下载与安装 · 兼容性说明 · 完整源码差异。

pipe 的非空标准输入持续流式读取到 EOF；空输入使用普通零字节 PUT，而不是未知大小的 multipart。显式校验和参数通过同一路径传给上传实现。quiet/非 TTY 模式下禁用进度条，同时对空输入与非空输入统一保留 JSON 结果输出。

2.14 - silo-pkg 3.14.0 发布

v3.14.0 于 2026-09-13 发布，源码提交为 827f8109，模块导入路径为 github.com/pgsty/silo-pkg/v3。

密码策略迁移

本版调整了密码修改的授权语义：

• 公共方法 Policy.IsAllowedActions 默认放行 admin:ChangeMyPassword（除非策略显式 Deny），而创建或管理他人的 admin:CreateUser 仍必须显式 Allow。在配套升级后的 Server 与 Console 中，仅拒绝 admin:CreateUser 不再禁止调用者修改自己的密码；若需禁止自助改密，须显式拒绝 admin:ChangeMyPassword。
• 内置 readonly 策略移除了原先的 admin:CreateUser Deny 规则（若同一主体还绑定了另一份授予 admin:CreateUser Allow 的策略，该授权将正常生效）。新增的 consolereadonly 策略包含存储桶列举能力，并采用相同的权限拆分；两份内置策略本身均不授予任何用户管理权限。
• 集群中已保存的自定义策略与用户级权限覆盖不会自动改写。

如果希望维持旧版“同时禁止创建用户和自助改密”的限制，请在升级前将 admin:CreateUser 与 admin:ChangeMyPassword 写入同一条 Deny 语句（保持原有的资源范围与条件），并在整个回滚窗口期内保留该配置——旧版 Server 不会在改密端点上单独识别 admin:ChangeMyPassword 的拒绝规则。详见密码权限迁移指南。

后续配套版本（9 月 16 日）： Console v2.4.1 已发布配套密码管理界面，并搭配 silo-pkg v3.14.1 与 mcli 20260916。全栈协调升级要求见组件版本矩阵。

依赖与验证

• 上游 minio-go 升级： 锁定至 v7.3.1-0.20260910142817-60bd07042d49，纳入可配置上传大小上限、流式请求 Content-Type 签名、RDMA 调用方 TLS 信任传递、列举操作校验和一致性以及归档恢复状态解析修复。
• 工具链与依赖刷新： 更新 golang.org/x/* 依赖，维持 Go 1.26 最低版本要求与 Go 1.27.1 构建工具链，所有导出 Go 函数签名保持不变；维持 go-systemd v22.6.0 replacement 以确保 NetBSD 交叉编译兼容。
• 测试与安全扫描： 通过 Go 1.26.8 与 1.27.1 全量 -race 测试、lint 及 LDAP 配置校验，并确认可通过 Go module proxy 与校验和数据库正常拉取。govulncheck 1.8.0 扫描确认无已导入的可达漏洞包（仅未导入受影响子包的 OpenPGP 模块保留 GO-2026-5932 记录）。

本版继续包含 v3.13.3 的策略 Deny/NotResource 序列化修复与有界通配符匹配算法（此前因旧版 bug 丢失语句的策略仍需从原始备份恢复）。自 v3.13.0 引入的 github.com/pgsty/silo-pkg/v3 模块路径迁移已在四个维护组件中全部完成。

相对 v3.13.3 的源码对比 · 上游改动采纳记录

2.15 - SILO Console 2.4.0 发布

v2.4.0 于 2026-09-08 发布， 源码为 c103d08e。

已发布行为

• 对象目录默认每页 100 条，可选 50、100、250、500、1000。每页只发一次 S3 continuation-token 请求；排序、筛选和选择作用于当前页，不扫描整个目录，没有无限制的“全部”模式。
• 版本删除绑定选定对象，目录删除限制在其前缀内。生命周期编辑保留独立动作和界面未暴露的字段，复制规则删除统一保存。
• 暂时网络故障不清空会话；处理空版本控制状态、损坏的侧栏偏好与过时的下拉选择。
• Server 显式启用嵌入信任策略时恢复 Console loopback 代理行为，独立部署信任默认值不变。
• 依赖 pkg v3.13.3、MC 源码 v0.0.0-20260908140805-c8aa5d25a63a 与上游 SDK 0e78d3f18efe。本版只引用 MC 源码，本身没有发布新的 mcli 标签。

修复后的 Deny/NotResource 语句保留行为可能拒绝曾因去重缺陷而成功的请求。 已经丢失的语句需要从原始策略恢复。嵌入方必须复制标签对应 README 的 MC replacement。

后续版本

Console v2.4.1 提供共享下载限制、密码权限拆分、 多对象流式 ZIP、浏览器恢复与可验证发布制品，使用 pkg v3.14.1 和 mcli 20260916。 v2.4.0 使用较早的浏览器内存 ZIP 路径。升级前请阅读密码权限迁移。

v2.4.0 精确发布源码通过完整 Console CI。变更详情见 标签 changelog、 对象浏览器指南与 发布附件。

2.16 - Silo Console 2.2.0 发布说明

发布日期： 2026-08-26 · 版本： v2.2.0（7dc4258a6）· 仓库： pgsty/silo-console

SILO Console 2.2.0 新增面向日志与结构化文本的有界预览，收紧下载错误处理以防止截断的压缩包被当作完整文件交付，修复数据表格行操作的权限门控，将用户启停状态与用户组变更拆分为独立 API，并在写入前校验数据库通知 DSN 与 IAM 策略文档。

在底层，依赖栈迁移到 Go 1.27.0，并切换到 SILO 维护的组件：pgsty/silo-pkg 3.12.1 取代上游 minio/pkg，pgsty/mc 取代上游 mc 库依赖，minio-go 升级到 7.3.0，etcd client 系列升级到 3.7.1，修复 CVE-2026-73500。

自 v2.1.1 以来的最终变更集共 33 个提交，涉及 176 个源文件（+8,794/−2,057 行，不含重新生成的嵌入式前端资产）。

为什么版本号是 2.2.0： 本周期切换了共享策略与证书实现的依赖提供方、跨越了 etcd client 的 minor 版本边界、拆分了一条 REST 路由，并调整了文件夹下载的失败语义。

日志与结构化文本预览

对象浏览器现在可以把 .log、.txt、.json、.xml 对象作为纯文本预览。实现刻意保持多疑——「在管理界面渲染桶里的任意内容」本质上是一份 XSS 邀请函：

• 构造上就有界。 请求携带 Range: bytes=0-1048576；响应以流式读入固定缓冲区并设硬上限，Content-Range/Content-Length 与实际读到的字节严格互验。超过 1 MiB 的对象报告过大——绝不会把片段当成完整内容渲染。
• 要么是文本，要么不渲染。 字节必须通过严格 UTF-8 解码（TextDecoder 开启 fatal）且不含 NUL；否则报告不可预览，而不是渲染乱码或二进制垃圾。可预览性是精确白名单——四种扩展名加精确的 MIME 类型 text/plain、application/json、application/xml、text/xml——.html/.htm/.xhtml 被显式排除，即使其元数据自称 text/plain。
• 没有活动文档。 内容渲染进单个 DOM 文本节点——不用 innerHTML、不用 iframe、不做 JSON 到 HTML 的变换。回归套件投喂 HTML、SVG、XML 载荷并断言它们保持为惰性文本。
• 对竞态免疫。 快速切换对象时，进行中的预览按代际失效，慢返回的旧对象响应不可能覆盖当前对象。取消与重试都是一等状态。
• 匿名可用。 公开/匿名对象页面通过匿名请求路径获得同样的预览，不触发任何带凭据的 API 调用。

围绕新预览类型，既有预览管线也一并修正：空对象预览为空而不是报错，追加写入的日志按新长度重新预览而不是按过期的列表尺寸截断，快速切换对象时的元数据竞态已消除。预览与分享对话框现在拿到对象的真实大小（92e8f4e65）。

下载完整性与进度计算

下载路径（进度上报、单对象、文件夹、归档与字节范围）统一改为严格校验完成状态与错误返回。

未知总大小时的进度显示

缺失、非法或自相矛盾的总大小不再变成编造的百分比：进度指示器保持不确定态，直到真实总量已知。零字节对象被显式归一化而不是落进未知总量路径；中止与取消是终态——迟到的进度事件不可能复活一个已取消的下载。下载请求恰好结算一次，JSON 错误体被安全解析，生成的对象 URL 会被回收。

流式文件夹下载

单文件夹下载改用浏览器原生的流式下载路径，不再把整个 ZIP 累积在 JavaScript 内存里——几个 GB 的文件夹不再有标签页崩溃的风险。交接模型的一个后果：控制台的传输管理器在把流交给浏览器的那一刻即报告完成（有 toast 说明），此后由浏览器自己的下载 UI 接管——交接后在控制台里取消不会停止浏览器侧的传输。多选下载仍走既有的 POST 响应，因此仍是内存 Blob；改变这一点需要单独的 API 决策，不在本版本范围内。

ZIP 完整性——一项刻意的行为变更

字节范围与状态码

• 畸形或不可满足的非空 Range 头现在返回 416 并携带 Content-Range: bytes */N，而不是 500。Range 解析比 Go 的宽容默认更严格：带符号、内嵌空白、bytes=-0、空 range 元素都会被拒绝。
• 对零字节对象的 range 请求返回空 200 而不是 500——这正是空对象预览 bug 的根源。
• 惰性对象 Stat 的失败现在透传真实的 S3 状态码（403、404……）而不是一律 500。
• 206 响应在写响应头之前设置 Content-Length，部分响应从此携带正确的帧信息。
• 对象大小现在总是序列化——REST 与 WebSocket 列表对零字节对象返回 "size": 0 而不是省略字段，UI 显示 0 B。这是「诚实进度」赖以成立的地基。

版本历史

S3 合法的 null 版本 ID 保持可见而不被丢弃，版本计数把前缀匹配过滤到精确对象，桶版本控制被暂停或禁用后历史仍然保留。

真正生效的权限门控

行操作按钮从未被禁用过

每个带数据表格的页面都把权限谓词传给了一个表格组件早已不读取的属性名（disableButtonFunction）——于是 10 个受影响页面（用户、用户组、策略、IDP、Webhook 设置、桶的访问/复制/生命周期面板）上的查看/编辑/删除按钮无论有无权限一律可点。谓词现在接到组件真正接受的属性上，并有一个源码守卫测试：死属性名再次出现即构建失败。服务端授权从未受影响——没权限点了也只会报错——但 UI 从此如实传达权限，而不是撒谎。

独立的服务账号能力

访问密钥管理过去把多个 UI 决策挂在一个合并的权限检查上。2.2.0 在一个模块中推导四项独立能力——List、Create、Update、Remove——并在自助 Account 页面与管理员的用户详情页面一致地应用：

• 能 list 才显示服务账号标签页，能 create 才显示创建按钮，能 remove 才允许行选择与批量删除，能 update 才显示编辑铅笔；
• View 现在是真正的只读：所有字段禁用、没有提交路径、回车键失效——以前「查看」打开的是可编辑对话框；
• 会话通告的 Create Access Key 能力对请求作用域策略的计算修正为：以 svc:DurationSeconds 为条件的 Deny（一种只有在具体请求存在后才能求值的有效期限制）保持该能力可见——包括通配符管理动作——而无条件或登录期即可判定的 deny 现在会正确隐藏它。最终授权仍由 SILO 在请求时裁决。旧代码对任意条件 deny 都保持能力可见，属于过度通告。
• 新增一条 OIDC 创建/列举/查看/删除的集成回归，走 UI 的显式凭据端点，并断言预期中的自我更新拒绝。

写入前校验 IAM 策略

命名策略与服务账号策略写入现在会在调用 Admin API 之前拒绝畸形文档和裸 S3 资源 ARN，并返回客户端错误。为兼容历史数据，旧策略读取仍保持宽容；但不兼容的已存策略必须先修正，才能再次保存。严格解析与资源检查位于控制台自身写入路径，而不是导入分支专有的策略 API，因此仍能维持对上游 minio/pkg v3.6.1 的源码构建下限。

匿名页面回归匿名

匿名对象浏览页不再发出只会产生 Access Denied 噪音的受保护 Object Lock/保留策略请求，并补上了语言（文/A）与暗色模式切换控件。

用户状态与用户组从此是两个操作

切换用户的启用/禁用状态与编辑用户组过去是一条合并的 PUT /user/{name} 调用，两个载荷都必填，且合并的权限门控导致仅仅编辑用户组也要求 admin:EnableUser。2.2.0 将其拆分：

• PUT /user/{name}/status（新增）只改状态，校验取值为 enabled|disabled，并拒绝当前登录用户启停自己。失败的切换不再让开关脱离同步——UI 反映服务器的答案，而不是乐观翻转。
• PUT /user/{name}/groups（既有）成为用户组编辑的唯一调用，不再要求 admin:EnableUser。
• PUT /user/{name} 在线协议上原样保留，作为已弃用的兼容端点服务既有 API 消费者；未知状态在该端点现在返回 400 而不是 500。

API 契约细节（含重新生成 Swagger 客户端的注意事项）见兼容性。

所写即所存的数据库通知表单

PostgreSQL 与 MySQL 事件目标表单围绕一个共享的 DSN 解析器/序列化器重写：

• 结构化字段与原始连接串是同一份状态：原始串在结构化字段被编辑前保持权威；一旦编辑，就重建规范化 DSN——PostgreSQL 使用 libpq 关键字/值引用规则，MySQL 使用感知 IPv6 方括号的 go-sql-driver 格式。模式切换不再破坏手工输入的字符串。
• 生成的预览掩码凭据；掩码不可能进入 API 载荷（载荷始终使用原始连接值）。
• 保存要求连接串与表名同时存在，清空的值会真正传播。
• 服务器现在拒绝其配置语法会破坏的 DSN——内嵌换行、会被解析成兄弟配置键的值（比如密码里含 table=）、不平衡的引号——在存储之前返回 400，且不把提交的机密回显在错误里。
• 各通知目标（Kafka、Redis、MQTT、NATS、Webhook）的通用密码与令牌字段渲染为密码输入框，包括被环境变量覆盖的值。

准确的待重启状态

配置的新增、更新、删除、重置现在尊重服务器实际返回的是否需要重启，而不是硬编码「需要重启」（或者更糟——弄丢它）。待重启标记是单调的：一旦有操作要求重启，后续不要求重启的操作不能清除它——只有真正的服务重启才能。

上传提示

超过 5 GiB 的浏览器上传会收到不阻断的提示：控制台以单个不可续传的请求上传，这个量级应该用 mcli 的分片上传。

会话、指标认证与 i18n 加固

• 会话快速失败。 匿名/空会话立即得到 401，而不是挂在一个空凭据的 Admin 请求上。控制台同时接受规范的 401 与旧式 403 无效会话响应；过期会话的重定向感知子路径——部署在 /console/ 下的控制台在自己的基路径内重定向。
• Prometheus Basic 认证全路径生效。 健康检查与根路径回退探测现在都发送 Basic 凭据（以前只发 Bearer，导致 Basic 认证的 Prometheus 让所有仪表盘组件被禁用），Bearer 令牌保持优先，且所有响应体都被排空，keep-alive 连接得以真正复用。
• 占位符替换在构造上转义安全。 翻译占位符填充使用一趟式字面格式化器：值中的 $&、$1、$`、反引号、花括号保持字面，重复占位符全部填充，并有一个 AST 源码守卫测试禁止不安全的 String.replace 模式回归。

工具链与依赖

Go 1.27 基线

SILO 分支

require github.com/minio/pkg/v3 v3.6.1

replace github.com/minio/pkg/v3 => github.com/pgsty/silo-pkg/v3 v3.12.1
replace github.com/minio/mc => github.com/pgsty/mc v0.0.0-20260806055018-b0021fd01ccb

• silo-pkg 3.12.1 是正式发布依赖。 pgsty/silo-pkg v3.12.1 已于 2026-08-25 发布，控制台直接固定它。它建立在 3.12.0 之上，继承策略资源边界加固、条件键查找、LDAP 与证书监视器修复，以及 Go 1.27 / etcd 3.7 依赖基线。
• mc 库依赖切换到 pgsty/mc 分支，使用日期式伪版本；导入路径不变。
• require 行刻意停留在上游 v3.6.1。 Go 会忽略依赖模块中的 replace 指令：下游模块 require 本控制台时，解析到的是上游 minio/pkg，而 SILO 的 v3.12.1 标签在上游并不存在。要求真实上游标签保证控制台对下游可解析；replace 只在控制台自身构建时应用分支。最终 CI 针对上游 v3.6.1 验证了公共源码构建表面。注意这只是编译层兼容——没有自带顶层 replace 的下游构建得到的是上游行为，不含分支的 SILO 专有 IAM 语义。
• go-systemd 回钉到 v22.6.0：v22.7.0 在 NetBSD 上使用了那里不存在的 CLOCK_MONOTONIC，无法编译；钉住直到上游修复发布。

etcd 3.7.1——仅客户端库

三个 etcd Go 模块一起从 3.6.8 移到 3.7.1，关闭 TLS 监听器拒绝服务漏洞 GO-2026-6107 / CVE-2026-73500。etcd 3.7 移除了遗留 protobuf 实现并使 clientv3.New 变为非阻塞——这些迁移只影响自行构造客户端或内嵌服务器的消费者。控制台两者都不做：它唯一的 etcd 路径是 silo-pkg/quick 操作一个已创建的客户端，只用普通的 v3 Get/Put。本次升级只涉及编译进二进制的客户端库——不触碰运维方的 etcd 服务器、集群数据或部署拓扑；服务器升级到 3.7 仍需遵循 etcd 官方的逐 minor 升级流程。

第三方维护保持克制

最终版本在独立兼容性审查后把 minio-go 升级到 v7.3.0，迁移其 INI 导入路径，并增加 lifecycle-filter XML 兼容覆盖。控制台侧的兼容解码器可以接受旧服务器返回的 legacy AccountInfo tag payload。其他已接受的维护变更包括 jwx v2→v3 与 httprc v3、go-openapi/swag/conv+typeutils 0.28.0、grpc-gateway 2.29.0、cheggaaa/pb 1.0.30 和 go.yaml.in/yaml/v3 3.0.5；无关的更大规模 go-openapi、pb/v3、压缩库与测试库升级仍然推迟。

前端方面，漏洞检查工作流扩展到 push、手动触发与开发依赖，使用不可变安装；刷新了有漏洞的传递依赖解析（fast-xml-parser 5.11、nanoid 3.3.18、@babel/core 7.29.7），移除了死导出与未使用的 http-status-codes 依赖。fast-xml-parser 5.x 的传递依赖树仅用于开发阶段，不进入浏览器构建产物。

安全评审

• 发布树上的 govulncheck：零个可达的漏洞符号，零个受影响的导入包。Swagger 构建工具单独扫描，同样干净。
• 依赖迁移关闭的漏洞：CVE-2026-73500（etcd TLS 监听器 DoS）、CVE-2026-56864 / CVE-2026-56865（x/mod 校验）。
• 仍会报告、但依旧不可达：模块级 GO-2026-5932 openpgp 公告——控制台不导入 x/crypto/openpgp，且该公告没有修复版本。
• 文本预览按 XSS 攻击面评审（见上文）；其回归套件包含活动载荷测试。
• 权限门控修复属于 UI 真实性修复：2.1.1 中服务端授权从未被绕过；只是控制台显示了不该显示的控件。

兼容性

部署层面一切不变： 环境变量、配置格式、命令、二进制名、systemd 单元、端口、嵌入数据布局均无变化。发布二进制保持自包含；Go 1.27.0 仅是构建期要求。

HTTP API 契约（控制台自身的 REST API）：

运维者可能注意到的行为变化：

1. 对部分可读前缀的文件夹/ZIP 下载失败，而不是静默省略不可读对象（详情）。
2. Range 解析比 Go 的宽容默认严格；畸形 range 头（bytes=-0、空元素）现在得到 416 而非尽力处理。
3. 只是碰巧能用的数据库通知配置（DSN 在写入途中被配置语法破坏的那种）现在被前置拒绝并返回 400。
4. 策略无条件拒绝创建访问密钥的会话不再显示创建控件（以前任意条件式拒绝都保持可见）。
5. 待重启指示会持续到真正重启为止，不再会被后来一次无关的配置变更清除。
6. 如果控制台前面的反向代理压缩了 /api/v1/…/download 响应，文本预览的严格 Content-Length 校验会把所有预览判为错误。控制台自身只压缩静态资产——请让代理对 API 响应保持不压缩。

已知限制与后续跟进

修复表格操作按钮禁用属性后，暴露出两处既有谓词把行对象与字符串直接比较的 UI 缺陷：

• 「不能删除 Default IDP 配置」的行守卫将行对象与字符串 "Default" 比较，导致按钮未禁用（IDPConfigurations.tsx）；
• 「不能删除环境变量覆盖的 Webhook 端点」的行守卫存在同样的对象与字符串类型不匹配（WebhookSettings.tsx）。

两处操作在提交时仍由服务端拦截。此外，新的 PostgreSQL DSN 解析器在填充结构化字段时仅解析规范的 key=value 语法（非常规但 libpq 合法的 DSN 会显示为空结构化字段，编辑结构化字段时会用这些字段重建 DSN）；TestCafe/Playwright 断言覆盖 UI 门控，服务端拒绝路径由集成测试套件覆盖。

验证

发布决策综合了本地候选阶段证据，以及在精确标签树 7dc4258a6 上执行的远端门禁：

本地发布准备门禁 —— go build ./...、go vet ./...（含 -tags testrunmain）、gofmt、golangci-lint、go test -race ./...、go tool swagger validate、govulncheck、TypeScript tsc、Playwright、Prettier、knip、linux/amd64 与 linux/arm64 发布标签交叉编译、go mod verify。

嵌入资产确定性 —— 前端经完整流水线（yarn build + 嵌入优化）从源码重建，与提交的 web-app/build 对比：逐字节一致，零脏文件。早期候选 19047161f 之后的九个提交修改 Go 兼容性、workflow 与浏览器测试时序，没有修改产品前端源码或嵌入资产。

最终树 CI 完整矩阵 —— Workflow 32888892876 报告 32 个成功 job，另有一个明确禁用的 React 测试占位项。覆盖 lint、semgrep、Go 与 API 测试、五个交叉编译目标、Swagger 漂移、最新 MinIO 源码构建、分布式集成、站点复制、封闭 SSO、完整 TestCafe 权限矩阵、subpath-nginx、Playwright 与覆盖率门禁。Vulnerability Check 32888899120 在同一提交上两个 job 全部通过。

发布流水线 —— goreleaser 32916237254 针对 v2.2.0 的两个 job 全部通过，并发布公开 GitHub Release。

下游契约 —— 在删除全部 replace 的临时树中，go mod tidy + go build ./... 针对上游 minio/pkg v3.6.1 成功，证明分支替换不会把分支独有符号泄漏进公共模块表面。

本周期一并交付的测试基础设施修复（让上述门禁真正起门禁作用）：Docker 承载的集成/复制/SSO 套件回到 testrunmain 构建标签之后（裸 go test ./... 不再试图启动容器）；SSO 门禁封闭化——不再 sudo 修改 /etc/hosts、不再临时 pip 安装、固定 SILO 镜像、自选端口、真实清理；集成门禁断言新的 416 range 语义并停止把 PostgreSQL fixture 绑定到主机端口；浏览器门禁通过发布 fixture 端口实现脱离 Linux 运行；修复了残存的品牌重塑前「MinIO administrator」选择器；有状态的 TestCafe 套件改为串行；Playwright CI 以不可变方式安装提交的锁文件。

发布制品

v2.2.0 GitHub Release 公开发布：

1. 六个独立二进制：Linux amd64/arm64/armv6、macOS amd64/arm64、Windows amd64；
2. 九个 Linux 软件包：amd64、arm64、armv6 各自的 DEB、RPM 与 APK；
3. silo-console_2.2.0_checksums.txt，以及 GitHub 为每个制品记录的 SHA-256 digest。

相关提交

• 16960f7ab — fix: keep unknown downloads indeterminate
• 5968bb37d — chore(deps): align the SILO Go dependency stack
• 288ab1240 — fix: harden sessions, metrics, and translations
• ecf3bb492 — fix: harden object previews and downloads
• 902d9650d — chore: tighten dependency and test gates
• 194c70c7a — build: prepare SILO Console v2.2.0
• 927b44e26 — fix: harden database notification forms
• da2191be9 — fix: clarify console upload and secret limits
• 6141c2445 — build: refresh SILO Console v2.2.0 assets
• 097e76155 — chore(deps): bump the shared package fork to v3.12.0
• 99ca523d6 — fix: split user status updates out of the combined user route
• f4097992f — fix: honor the server restart result for configuration changes
• f1280032a — fix: restore permission-gated table row actions
• 24ce0af97 — fix: keep request-scoped access key conditions visible in the console
• 92e8f4e65 — fix: pass the object size into the preview and share dialogs
• 8f6fb3c78 — test: make the SSO gate hermetic and pin it to a SILO release
• 384a2cb95 — build: refresh SILO Console assets and record the changes
• a73cda376 — test: fix the integration gate’s stale range and host port
• cf5049c1d — test: make the browser gates runnable and fix a stale selector
• 6fa19d857 — fix: complete service account permission boundaries
• 7e57771a4 — build: refresh SILO Console assets
• 57cfe7aa0 — fix: restore downstream and browser release gates
• 19047161f — test: stabilize permissions browser gates
• e37dec873 — fix: validate IAM policies before writes
• 28505ed23 — chore: update minio-go to v7.3.0
• 16abb971e — ci: harden validation and release gates
• 2ddfcd036 — fix: accept legacy AccountInfo tag payloads
• 31332bca9 — fix: preserve policy source compatibility
• 3a8251086 — ci: allow permission tests to finish
• c159fff78 — ci: serialize shared-role permission tests
• 2e91cdf9a — test: wait for watch controls to become ready
• 7dc4258a6 — test: allow asynchronous UI controls to settle

链接：

• SILO Console 源码 · v2.2.0 Release
• silo-pkg 3.12.1 Release · silo-pkg 3.12.0 发布说明
• SILO 官网 · 文档

2.17 - SILO Console 2.5：界面与管理功能更新

SILO Console v2.5.1 现已正式发布（源码提交 fff1618d9abb），同时作为 SILO 20261026 的内嵌控制台交付。本文完整汇总自 v2.4.2 以来的 2.5 系列变更，涵盖 v2.5.0 的界面重构与 v2.5.1 的问题修复。

GitHub Release · 下载 · 完整源码对比

导航、概览与监控指标

2.5 系列重构了整体界面视觉与交互：采用柔和的明暗主题配色、系统原生字体、统一的信息密度、Lucide 图标库、清晰的键盘焦点样式，并支持系统的“减少动态效果”（Reduced Motion）偏好。移动端抽屉与平板窄侧栏针对小屏做了专门适配，对象详情在移动端以可恢复焦点的底部抽屉呈现，同时完整保留中英双语切换、无障碍控件与开源许可署名。

左侧导航按当前会话的实际权限组织 Identity、Monitoring、Settings 与 Tools 分组，合并了统一的 Buckets 入口与最近访问存储桶列表，并保持登录重定向目标与既有对象深链接兼容（/browser 自动跳转至 /buckets，桶管理根路径默认进入 Summary 页）。Help 菜单继续提供文档、视频与 Blog/RSS 入口。

Overview 概览页直观展示节点与磁盘健康状态、原始物理容量、活跃告警、快捷操作及数据刷新时间。容量直接采用 Server 上报的实测值（不凭空估算纠删码可用容量），缺失的统计项明确显示为未知。Monitoring 下的 Metrics V3 面板严格区分“样本缺失”与“真实零值”，并正确处理逐节点重复导出的集群指标。注意：尽管 Server 20261026 已支持返回实时存储桶清单，存储桶与账户的对象用量统计仍由后台扫描器异步汇总。

存储桶、对象浏览器与任务中心

• 存储桶列表： 支持排序、名称筛选、URL 查询参数持久化、表格/卡片视图切换、大列表虚拟滚动及未知用量标注；使用稳定的行标识防止排序后选错目标桶，并在页面跳转后自动丢弃在途的旧搜索结果。
• 细粒度权限体验： 仅具备写入权限的用户也可正常进入对象工作区；完整保留桶根通配授权与前缀访问限制；修改标签等操作被服务端拒绝时直接展示服务端返回的错误原因（列举、读取与修改权限仍各自独立判定）。
• 在线预览与命令提示： 支持最大 1 MiB 的文本、Markdown、CSV/TSV 表格预览、源码高亮、安全 HTML 渲染及明确的截断提示；常用配置表单可直接生成脱敏的等价 mcli 命令。
• Tasks 任务中心： 统一跟踪文件上传下载、原生流式 ZIP 打包下载、批量删除、历史版本清理与对象恢复任务；写操作并发受控，重试仅针对失败条目（取消任务不会回滚已完成的写入；大文件或流式 ZIP 下载触发浏览器保存后，请在下载完成后核对本地文件完整性）。
• 键盘导航与分页： 新增键盘上下移动、Shift 范围选择、当前页全选、快捷键面板与按权限裁剪的右键菜单。对象列表继续采用游标分页，排序、名称筛选与全选仅作用于当前页。

身份管理与高延迟诊断

用户详情页集中展示账号状态、直接绑定策略、用户组继承策略与 Access Key 数量；策略管理页明确区分原生内置策略、已被覆盖的内置策略与自定义策略，并显示策略分配计数及受影响身份。原生内置策略默认只读（需显式确认后才允许覆盖），已被覆盖的内置策略提供一键 Reset 恢复原生定义。重新加载失败时会清空过期的编辑器内容，切换界面语言时保留未保存草稿，表单统一补齐无障碍标签关联并默认遮蔽远端密钥。

注意：内置策略 Reset 与实时存储桶清单需要配合 Server 20261026 使用。 单独升级独立部署的 Console 不会修复旧版 Server 的策略缓存，也不会替换旧版 Server 内嵌的前端界面。

在诊断工具面，Health、Trace、Logs、Watch、Speedtest 与 Profile 六类实时诊断流统一复用唯一的读取协程完成 WebSocket 关闭握手（Close 帧发送与等待共享 5 秒超时预算，且不打断正常活跃流），彻底修复了 Azat / @azataiot 在 #63 中报告的高延迟链路下健康报告截断与 1006 异常关闭问题（超时错误返回标准 1008 状态码，不泄露内部堆栈细节）。同时，健康报告下载在版本探测与正文读取之间复用同一个 JSON 解码器以保留预读缓冲帧，拒绝被截短、已取消或失败的响应流，并保持 madmin v3 的签名传输与重试策略。

2.5.1 补丁修复

• 用户组状态切换（#67）： 单独切换用户组启用/禁用状态时保留组内现有成员；显式传入 members 数组时仍按原语义替换成员列表。
• OIDC 组权限与反向代理会话（#66）： 正确保留 OIDC 字符串数组格式的组声明权限；仅在启用了 HTTPS 或配置了可信 TLS 反向代理转发头时设置 Secure 会话 Cookie，不再盲目信任未校验的客户端转发头。
• 凭据导出与流式 ZIP 错误状态（#68）： Access Key 导出完整保留原始 UTF-8 JSON 字节；流式 ZIP 下载若在写出首个响应字节前失败，直接透传底层 S3 错误状态码。
• 无障碍与焦点恢复（#68）： 修复表格与表单控件的键盘焦点恢复、可访问名称及进度条数值属性；窗口尺寸变化导致标签栏重排时保持当前焦点标签可见。
• 配套依赖升级（#69）： 升级至正式版 mcli 20261026、silo-pkg v3.15.2 以及支持 HTTP 204 移除复制配置的上游 SDK。

依赖与交付验证

本版基于 Go 1.27.3、Node 24.22.1、Vite 8.3.5、GoReleaser 2.19.0、silo-pkg 3.15.2、mcli 20261026 与上游 minio-go 320af050c445 构建；为保持终端输出格式与跨平台兼容，继续固定 tablewriter v0.0.5、go-humanize v1.0.1、go-runewidth v0.0.29 与 go-systemd v22.6.0（详见统一依赖与安全审计清单）。

GitHub Release 提供各平台二进制归档、Linux 软件包、源码包、SHA-256 校验和、SPDX SBOM 以及 Sigstore/GitHub 构建溯源证明。Windows 归档改用 .zip 格式（Linux 与 macOS 保持 .tar.gz），官方多架构镜像已发布至 Docker Hub（docker.io/pgsty/silo-console:v2.5.1），核验步骤见发布契约。

前端静态资源与内嵌产物在隔离工作目录中完成逐字节可复现构建。SILO Console 正式维护的管理目标为 pgsty/silo（对上游 MinIO 保持尽力而为兼容），既有 CONSOLE_* 环境变量、API 路由、服务单元名称与 Go 模块路径均保持不变；详细的 API 与内嵌依赖说明见 Console 兼容性指南。

2.18 - silo-pkg 3.15：Go 1.27.3 与 S3 SDK 修复

silo-pkg v3.15.2 现已正式发布（源码提交 0416eb1f4505），由 SILO 20261026 组件栈以 github.com/pgsty/silo-pkg/v3 模块路径直接引入。本文完整汇总自 v3.14.3 以来的 3.15 系列更新（v3.15.0、v3.15.1 与 v3.15.2）。

3.15.0：Go 工具链与共享依赖升级

模块最低 Go 版本要求由 1.26 提升至 1.27.3，并同步更新了 13 个直接依赖模块：JWX 3.4.0、etcd api / client/pkg / client 3.7.3、gRPC 1.84.0、grpc-gateway 2.32.0、go-json 0.11.2、swag/conv 0.29.2、go-colorable 0.1.16、cpuid 2.4.1、fwd 1.2.1，以及固定在 ce908d29299b 的两个 Google API/RPC 生成模块。

下游应用需使用 Go 1.27.3 重新编译以纳入标准库证书校验修复。公开包 API、IAM 策略格式、授权判定逻辑以及 v3.14.3 的策略匹配性能优化均保持不变。

3.15.1：上游 S3 SDK 修复

v3.15.1 将上游 minio-go 从 v7.4.1 推进至 ab93db7ba435，合入了以下修复：

• 在发送不完整分片前直接拒绝被截短的顺序或并行流式分片上传。
• 修复 ReadAt 到达 EOF 后的顺序读取状态，并在访问元数据前拒绝负偏移参数。
• 修复调用 Object.Stat 之后的读取与 Seek 边界计算。
• 对批量删除回退路径中的重复错误去重，确保每个失败项只上报一次。

3.15.2：移除桶复制配置兼容

v3.15.2 进一步选用上游 v7.4.2-0.20261025165926-320af050c445（伪版本，上游尚未打 v7.4.2 标签）。移除存储桶复制配置（含向 SetBucketReplication 传入空配置）现在同时接受服务端返回 HTTP 200 与 HTTP 204，而 AccessDenied 等真实鉴权或请求失败仍正常返回错误（见上游提交对比）。

兼容性与验证

为保持既有 CLI 输出格式与 NetBSD 编译兼容，下游应用继续固定 go-humanize v1.0.1、go-runewidth v0.0.29 与 go-systemd/v22 v22.6.0。由于 Go 不会传递继承依赖模块的 replace 指令，各嵌入方需在自身 go.mod 中显式声明所需的模块替换。

v3.15.2 已通过含 LDAP 集成在内的全量 lint 与 -race 竞态测试、模块校验及三项 CI 流水线（Go、LDAP、VulnCheck）。HTTP 协议夹具验证了两个复制移除入口均同时接受 200/204 并保留 403 错误；此前的 3.15 依赖回归测试亦覆盖了 JWT 校验边界、本地 etcd 认证/Watch/租约持久化及 CLI 输出格式。模块级扫描中的 GO-2026-5932 位于未被导入的弃用 OpenPGP 包中，不影响运行代码（详见统一安全审计清单）。

require github.com/pgsty/silo-pkg/v3 v3.15.2

silo-pkg 仅作为 Go 源码模块发布，Server、Console 与 mcli 通过重新编译集成该版本。正式维护的依赖组合为 PGSTY 组件栈，对上游 MinIO/MC 保持尽力而为兼容。GitHub Release · 完整源码对比。

2.19 - Silo Console 2.1.0 发布

发布日期： 2026-08-06 · 版本： v2.1.0 · 仓库： pgsty/silo-console

SILO Console 2.1.0 是独立发布 2.0.0 之后的第一个功能版本，主要包含三项改进：

1. 双语界面——全部控制台页面、帮助条目与文档链接支持中英文切换，切换按钮出现在每一页，且不引入新的运行时依赖；
2. Metrics V3 仪表盘——仪表盘从 MinIO Metrics V2 指标迁移到 V3，并针对 V3 改变的底层语义做了显式适配；
3. 边界场景正确性修复——全选框与批量操作作用于同一批对象，占位符兼容包含 $& 的对象名，时间戳统一携带时区，空指标显示“无数据”而非虚构的 0。

这是一个 小版本。环境变量、模块路径、API 契约、二进制名称和数据布局均无变化，升级就是换二进制或换镜像。

双语控制台

这是一套对象存储的管理界面，而它的运维使用者中有相当一部分以中文为第一语言。2.1.0 在不引入 i18n 框架的前提下把界面变成双语——嵌入式交付意味着每一 KB 都要计入二进制体积。这对应 issue #6：该 issue 原本提议使用 i18next，而"零依赖"是本次实现相对它唯一一处有意的偏离。

实现方式

设计约束是：不加新依赖、不加构建步骤、不引入字符串抽取流水线，并且 部分覆盖绝不能让页面出错。

• 英文原文就是字典的 key。t("Create Bucket") 查找对应的中文条目；查不到则原样返回英文。因此覆盖度可以增量生长，写错 key 的后果是退化成英文，而不是暴露 console.bucket.create 这样的裸标识。
• 三份字典，一次合并。zh.ts（165 条界面框架）、zhHelp.ts（247 条帮助内容）、zhScreens.ts（1373 条功能页面）合并时以框架优先，合计约 1785 条。
• 语言偏好完全复用暗色模式的模式：localStorage → systemSlice → setLanguage。不做浏览器语言探测，默认英文，选择完全显式。
• 集中拦截而非逐点改写：页头包装器、确认对话框、帮助条目、路由定义、仪表盘面板渲染器各自在输出的最后一步翻译。这正是 220 个页面文件能够在不触碰业务逻辑的情况下完成本地化的原因。
• 模块拆分是必要的。i18n/lang.ts 只存放纯函数原语（translate、localizeUrl）且不导入 store——systemSlice 依赖它，反向导入会形成循环依赖。Hooks（useT、useLanguage、useLocalizedLink）与 interpolate() 放在 i18n/index.tsx。

切换控件是一个描边风格的 文/A 图标，挂载在所有页面的页头，登录页复用同一控件。

覆盖范围

登录与 SSO 流程、导航与命令面板、仪表盘与全部指标面板、存储桶与完整对象浏览器（上传、预览、分享、版本、回溯）、用户/用户组/策略/访问密钥、配置与事件目标、IDP 与 KMS、日志、健康报告、性能测试、性能剖析、对象检查、跟踪、监视，以及许可证页面。

除可见文本之外：

• 文档链接会本地化。silo.pgsty.com 的链接在中文下加 /zh 前缀；Pigsty 站点做域名对调（pigsty.io ↔ pigsty.cc）。GitHub、MinIO、AWS、YouTube 链接保持不变。
• 帮助面板的博客源按语言区分，中文下拉取 /zh/blog/index.xml，并为每种语言维护独立缓存。
• 命令面板在两种语言下都能搜到。菜单项显示时翻译，但保留英文原文作为关键词，因此"桶"和 “buckets” 都能命中。
• 图表图例只翻译静态前缀。translateLegend 保留 [server:drive] 这类实例后缀；数据层保留原始图例，所以那些依赖图例做数值匹配（容量求和）的组件继续正常工作。
• 时间戳统一携带时区格式，详见下文。

代价

嵌入负载增加约 61 KB（2.79 MB → 2.85 MB，+2.2%），零新增依赖，字典进入独立的按需加载分块。英文渲染路径字节稳定：使用默认语言时，输出与 2.0.0 完全一致。

保持英文的字符串

后端错误信息（182 条）由 Go 服务端产生，前端无法翻译。少量硬编码在 vendored mds 组件库内部的字符串——收起态菜单的 “Sign Out” 提示，以及数据表格的 “Columns”、“Loading…” 和 ON/OFF 开关——仍是英文；其中两处（“Sign Out”、“Actions:"）通过作用域 CSS 规则做了中文替换，其余需要改动 vendor 才能处理。

Metrics V3 迁移

仪表盘此前查询的是 MinIO Metrics V2 名称，而 SILO 部署抓取的是 V3（/minio/metrics/v3）——也就是说，仪表盘依赖的是监控流水线已经不再采集的端点。2.1.0 将全部 26 个部件 重写到 V3 目录——31 条查询，涉及 29 个不同的指标名——并移除三个从未被任何布局引用的部件（51/61/62）。这对应 issue #7，Info 页面的那一半是 #8。

这里的决定是 V3 only：不做运行时回退、不做探测、不提供版本选择开关。SILO Console 面向的是 SILO 部署，服务端、抓取流水线与控制台是一同交付的。SILO 服务端继续为外部消费者提供 V2 端点，只是控制台不再使用。回退机制在这里反而有害——保留 15 天 V2 序列的指标库会让 or 回退悄悄读到过期数据。

V3 改变的语义

有三条 V3 特性会让"照名字改写"的迁移出错，每一条都需要明确的应对：

1. 集群组指标由每个节点重复导出。/cluster/* 指标不带 server 标签，也不做 leader 门控，因此 N 节点的抓取会得到 N 条重复序列。查询统一用 max()/min() 聚合——绝不能用 sum()，那会把集群总量乘以节点数。
2. 零值默认不导出。任何取值 ≤ 0 的指标都会被跳过，离线磁盘数、修复中磁盘数、纠删集健康状态在取值为零时会直接从指标流中消失，导致统计卡片渲染成空白面板。所有受影响的查询都配了伴随守卫，让面板读出真实的 0。
3. 移除 minio_heal_* 命名空间。V2 的修复活动信号本身是内存态的（重启即清零，任意扫描都会刷新），现替换为两张语义明确的卡片：纠删健康（以写入法定人数为基线）和 用量数据时效（扫描器用量快照的陈旧程度）。

零值语义

本次迁移针对八类边界场景明确区分了 零值、无数据 与 尚未完成首次扫描：

• 容量 的空闲/已用以恒定存在的总量为基线，因此写满的集群显示 0 空闲，而不是整个消失。
• 在线磁盘 针对全部离线的场景加了守卫——恰恰是最需要看到这个数字的时候，零值跳过会抹掉面板。
• 桶与对象计数 改用用量组自身的新鲜度指标做守卫，因此尚未完成首次扫描的集群显示 无数据，而不是编造一个 0。
• 空的单值结果 渲染为 —，而不是 0。
• 空的大小分布 不再伪造七个零高度的柱子。
• 小数速率保持可见（parseFloat 轴域、两位小数的 CPU 格式化器），不再被压成 0。
• 不足一秒的用量数据时效 收敛到"1 秒”，而不是渲染成空白。

回归测试套件（api/admin_info_metrics_test.go）现在把每条部件查询钉死在 V3 目录上，校验部件 ID 唯一性，并强制执行逐部件的守卫分类法：健康与流量类需要在线节点数伴随项，用量计数类需要用量组新鲜度伴随项，容量类需要总量基线。完整映射记录在 docs/metrics-v3.md。

顺带修复

• 部件 17 把 sent_bytes 查了两次，部件 11 把 syscall_read 查了两次——两组节点间/系统调用的收发配对都退化成了重复项。
• 无标签矩阵（max() 聚合的结果）序列化时 完全没有 metric 字段，导致前端的标签提取崩溃，表现为容量环图显示 0 B、用量增长图为空。已加守卫。
• 一个从未被使用的逐部件 Prometheus label-values 预取请求，让每次部件请求最多多等一秒。已删除。
• 仪表盘的用量卡片、图表控件以及密集的流量/资源面板按统一语法重建，现在在平板宽度下也能正常重排。

工作中还发现两个 服务端 缺陷，选择上游跟踪而非在此绕过：minio_cluster_usage_buckets_since_last_update_seconds 发出的是纳秒（对象变体是正确的），以及 V3 桶级发送/接收流量被对调。

正确性修复

能扛住真实对象名的占位符

String.prototype.replace 会把 替换值中 的 $&、$'、$`、$1 当作指令解释。而 S3 的 key 合法地允许包含 $。于是一个名为 report$&.csv 的对象不会按原样渲染——它会把匹配到的占位符文本重新注入输出，破坏整条消息。全部 37 处 字典占位符替换现已改为传入函数形式的替换值，函数形式不做任何此类解释。该缺陷原本就存在于英文界面中，在本次本地化排查时一并检出修复。

与批量操作一致的全选

vendored 数据表格在缺少 onSelectAll 时会渲染一个无法翻译的纯文本 “Select” 表头——七张可选表格全都如此。更麻烦的是，直觉的修法是错的：直接用可见行替换整个选择集，会 丢掉被当前过滤条件隐藏的行，于是表头复选框与随后的批量操作可能作用于不同的集合。实现只切换当前可见行，并保留被过滤隐藏的选择，因此表头状态不可能再暗示一个与实际操作对象不同的集合。

带时区的时间戳

桶、对象、版本、回溯与访问密钥的时间戳此前混用冗长英文格式，并且有几处使用 不带 AM/PM 的 12 小时制——这根本是歧义的。现在它们在两种语言下统一渲染为 yyyy-MM-dd HH:mm[:ss] (ZZZZ)。

扛得住实时数据的翻译运行时

t() 同样会收到运行时字符串：User-Agent、RSS 标题、对象名。由此做了两项加固：

• 未命中时 无条件原样返回——隐式的 @context 后缀剥离被移除，因为它会悄悄改写恰好含有 @ 的实时数据；
• 字典查找加上 hasOwnProperty 守卫，因此恶意输入即便命中继承自 Object.prototype 的成员（constructor、toString）也无法把函数泄漏到界面上。

交互与可访问性

• 会话过期后打开深链会在 /login 之间 来回弹跳，不断累积重定向链，而不是干脆落到登录表单上（#1）。
• 收起态的侧边栏按钮没有可访问名称，屏幕阅读器只能报为未命名控件（#4）。访问密钥输入框现在显式声明 autocomplete 意图，而不是让密码管理器去猜（#5）。
• 移动端的指标与存储桶面板改为滚动，不再被裁切（#3）。
• 性能测试的控件行改为换行而不是溢出卡片，时长可填秒或分钟，大小的默认单位改为 MiB 以匹配其自身的单位列表。
• 侧边栏桶列表的虚拟行距与 44px 的行高对齐，选中与悬停高亮不再互相重叠。
• 单位标签渲染所选单位的 显示名，而不是原始取值。

没有 SUBNET，没有遥测

上游已移除 Subnet、Registration 与 Call Home，本项目继承了该状态，但仍残留三处痕迹。2.1.0 予以清除：

• 健康诊断 websocket 的 subnetResponse 字段从来就不指向任何 subnet——它只是一个"报告已生成"的哨兵值——现改为 reportStatus: "ok"；
• 两条帮助文案声称健康报告"会自动上传到 SUBNET"、检查输出"传输到 SILO SUBNET"。两者都不属实。它们现在描述真实行为：报告在部署端生成，由浏览器下载；
• 删除从未被引用的 CONSOLE_SUBNET_PROXY 常量。

顺带说明，2.1.0 的出网行为没有变化，仍然是：无分析、无遥测、无埋点、无外部脚本与字体。silo-console update 依旧禁用。版本目录仅在显式设置 SILO_RELEASE_SERVICE_HOST（或 RELEASE_SERVICE_HOST）时才会连接——没有默认值。浏览器唯一的自动出网请求是帮助面板的博客源，且只在用户打开 Blog 标签页之后发生。

升级指南

没有任何需要迁移的内容。2.0.0 到 2.1.0 之间，环境变量、模块路径、协议字段、systemd 单元、二进制名称与数据布局均无变化。

install -m 0755 silo-console-linux-amd64 /usr/local/bin/silo-console

有两点值得知道：

• 仪表盘现在要求 Metrics V3。如果你的 Prometheus 只抓取 V2 端点，仪表盘面板会显示无数据。请把抓取目标指向 /minio/metrics/v3；由 Pigsty 管理的部署已经如此。
• 语言默认为英文，按浏览器选择并存入 localStorage。不存在服务端默认值，也不做浏览器语言探测，因此现有部署升级后外观不会发生变化。

验证范围

打标签之前，针对最终代码树执行了以下门禁：go build、go vet、golangci-lint（0 问题）、全部 Go 包的单元测试、gofmt、TypeScript 类型检查、前端生产构建、全量 Prettier 检查、字典重复 key 检查，以及对完整 diff 的调试残留扫描。

嵌入负载从干净目录重建两次并确认逐字节一致，满足发布流水线零差异门禁的要求；Metrics V3 查询已在含真实集群数据的线上指标库上完成验证。

已知限制

• SSO 端到端测试套件依赖外部 OpenLDAP/Dex/MinIO 拓扑，本轮未在该环境中运行；OIDC 代码路径已由单元测试覆盖。
• 后端错误信息与若干 vendored mds 组件字符串仍为英文（见保持英文的字符串）。
• 中文翻译覆盖控制台自身的界面；帮助条目正文已翻译，但它们所链接的文档页面遵循文档站自身的语言覆盖情况。
• 两个服务端 V3 指标缺陷（桶用量时效的纳秒单位、桶级流量对调）在上游跟踪，控制台侧未做绕过。
• 自动自更新仍然禁用，升级需要显式执行。

已关闭的 Issue

2.1.0 关闭了针对 2.0.0 提出的全部 issue。每个 issue 在 tracker 上都留有一条评论，说明修复方式、涉及的提交，以及补充的测试覆盖。

有三项验收标准如实记为未达成，而不是含糊勾掉：web-app 目前没有单元测试运行器，因此 #6 的 i18n 测试套件与 #2 中针对 constructLabelNames 的专项测试都需要先引入测试工具链；另外 #6 要求的"如何新增翻译 key"的贡献者文档尚未编写。

关联提交与链接

v2.1.0 的完整变更由以下 20 个逻辑提交构成。v2.1.0 标签另外还带有三个更晚的文档提交，它们重写了仓库 README，不改变任何已交付的行为。

• 8764f5d — fix(web): stop recursive login redirects
• 437c56c — fix(ui): make the dashboard and bucket list usable on narrow screens
• 85fc0c6 — fix(a11y): name collapsed sidebar controls and credential fields
• e3fed07 — fix(metrics): rebuild dashboard cards, chart controls, and layout
• fa11576 — feat(login): polish controls and legal attribution
• 9fc17c1 — feat(i18n): add hand-rolled EN/ZH core, dictionaries, and language toggle
• 622c02e — feat(i18n): localize login, navigation, and the help system
• 6a03719 — feat(i18n): localize dashboard and metrics screens
• 14b1c2d — feat(i18n): localize bucket and object browser screens
• 0298062 — feat(i18n): localize identity, configuration, and event destinations
• 41094f6 — feat(i18n): localize observability, admin tools, and shared components
• e964992 — feat(metrics): migrate the dashboard to MinIO Metrics V3
• 0b2251f — fix(i18n): harden the translation runtime for live data and chart legends
• 9b60148 — fix(console): unify timestamps on a timezone-carrying standard format
• bf110ae — fix(console): give selectable tables a visible-rows select-all
• 5fc8f22 — fix(i18n): escape-proof all placeholder substitutions
• fef8fab — fix(console): polish speedtest, sidebar, and help chrome
• c4911e8 — chore(console): drop SUBNET remnants from health reporting
• 1d631c4 — docs: record the SILO Console v2.1.0 changelog
• 912d847 — build: regenerate optimized embedded web assets

相关链接：

• SILO Console 源代码 · Releases
• SILO 网站 · 文档
• 授权说明 · 来源归属 · 商标说明

2.20 - Silo Console 2.0.0 发布

发布日期： 2026-08-04 · 版本： v2.0.0 · 仓库： pgsty/silo-console

SILO Console 2.0.0 是这套对象存储管理控制台以独立项目身份发布的第一个主版本。它从 georgmangold/console 的 v1.9.1 维护线继续演进，完成了三件事：

1. 建立独立身份——产品名称、视觉系统、文档入口、源码归属与发布链路全部迁移到 SILO 项目体系，同时保留 Go 模块路径、环境变量等兼容契约；
2. 重塑用户界面——登录页、主题系统、仪表盘与全站细节按统一的设计语言重新打磨，配套全新的品牌图标集；
3. 强化工程质量——嵌入式前端资产从约 10MB 压缩到 3.5MB，已知依赖漏洞清零，并修复了包括运行时数据竞争在内的一批上游遗留缺陷。

为什么是 2.0.0

这套控制台最初源自 MinIO Console，随后由 Alevsk/console 与 georgmangold/console 两条社区维护线继续发展。SILO Console 在此基础上由 Pigsty 社区接续维护，为 SILO 提供浏览器管理界面。

版本号从 v1.9.1 提升到 v2.0.0，主要是因为以下对外契约同时发生变化：

• 产品名称统一为 SILO Console，主仓库迁移到 pgsty/silo-console；
• 正式发布二进制从 console 改为 silo-console；
• 发布资产、校验和、软件包元数据、命令行说明与项目链接全部切换到 SILO；
• 界面中的项目身份、帮助入口、版权归属、源代码供应与商标说明重新建立。

2.0.0 采取的是"对外身份清晰、对内兼容克制"的迁移策略：需要运维人员明确感知，但不对底层兼容接口做机械式改名。

名称与交付契约

容器部署使用 Docker Hub 的 pgsty/silo-console，当前版本及拉取命令见 Console v2.4.1 发布说明。

命令行程序的作者、用途、帮助文本和项目描述已切换为 Pigsty 与 SILO Console。DEB/RPM/APK 软件包的厂商、维护者、主页、描述与许可证元数据相应更新，可执行文件安装到 /usr/local/bin/silo-console。

刻意保留的兼容标识

以下名称保留 minio 或 console，属于接口、协议或安装兼容层的一部分：

因此，升级脚本不能执行全仓库或全配置的 minio → silo、console → silo-console 替换。未来若要迁移这些兼容接口，需要提供别名、弃用周期和明确的双读策略。

全新界面

2.0.0 对整套控制台界面进行了端到端重构。

登录页

登录页完全重写：左侧品牌面板以纯 Canvas 生成缓慢流动的正弦光网动画（零外部依赖，遵循 prefers-reduced-motion，切至后台标签页时暂停），文案以 “Keep the S3 Interface / Own the Object Store” 呈现项目主张，底部保留完整的 MinIO 商标声明；右侧表单功能与既有自动化测试选择器完全不变。SILO 字标所用的 Chakra Petch 字体以约 20KB 的本地子集打包，不产生任何外部网络请求。

统一主题系统

控制台的全部颜色收敛到一个亮暗两套的主题层：中性灰阶承载正文与边框，品牌钢蓝色承载主操作与选中态，侧边栏在明暗模式下统一使用与登录页同源的深色系。表单控件与卡片采用统一的圆角与过渡，输入框获得键盘焦点光环，模态框有入场动画（同样遵循 reduced-motion）。服务端下发自定义样式（customStyles）的优先级保持不变。

控制台细节

• 仪表盘（Metrics）：统计卡片按统一语法重构——弱化标签、等宽数字、状态圆点对齐；环形图与信息条接入主题；移除了上游实现中的绝对定位布局。
• 空态统一：Watch、Trace、桶事件/复制/生命周期等所有数据面板的占位文本统一为居中弱化样式，不再是左上角的裸文本。
• 垂直选项卡：桶详情等页面的选项卡从带边框的灰色矩阵改为安静的药丸列表，并消除了栏底的空白残留格。
• 许可证页：新增 VERSION 区，同时显示所连接服务端的版本与 Console 自身版本；无 admin:ServerInfo 权限的账号不会发起请求，该行自动隐藏。页面同时集中说明 AGPLv3 授权、AGPL 第 13 节下的源码获取权利、来源谱系与商标边界。
• 一批交互修复：移动端首次加载即收起侧边栏（原先要等窗口 resize 事件）；侧边栏底部导航不再在窗口高度变化时延迟跟随；桶列表手风琴的高亮条铺满整行；仪表盘在窄屏下不再产生隐式横向溢出；帮助面板改为真正的按需加载——登录页不再向任何外部站点发起请求。

品牌图标集

favicon、PWA 与 Apple Touch 图标此前仍是上一代手绘徽标的 PNG 导出。2.0.0 将全部尺寸（ico 16+32、favicon 16/32/96、apple 180、manifest 192/512）从官方 silo.svg 矢量徽标重新光栅化，主屏尺寸带防裁切安全边距；Web App Manifest 裁剪为现代图标集，移除 2014 时代的 legacy density 条目。图标总体积从 473KB 降至 160KB，浏览器标签页图标从此与站内品牌完全一致。

更小、更快

嵌入式交付是这套控制台的核心形态——前端资产通过 go:embed 打进二进制。2.0.0 对这条链路做了系统性优化：

• 嵌入负载从约 9.6MB 降至 3.5MB。文本资产（JS/CSS/SVG 等）在构建期以确定性 gzip 预压缩后嵌入；仅被现代浏览器忽略的 legacy WOFF 字体（约 1.25MB）、以及一批完全未被引用的孤儿图片资产被移除。
• 首屏传输从约 5.7MB 降至约 1.7MB。此前静态资产完全未压缩传输；现在预压缩资产直接以 Content-Encoding: gzip 发出（零运行时压缩开销），对极少数不接受 gzip 的客户端动态解压回退。
• 正确的 HTTP 语义。Accept-Encoding 按 RFC 9110 完整解析 q 值（gzip;q=0 会得到未压缩内容），响应携带 Vary: Accept-Encoding；静态路径与 SPA 入口对非 GET/HEAD 请求返回 405 并带 Allow 头。
• 可复现构建。压缩使用纯 JS 实现（fflate）以保证跨平台字节级确定性；发布流水线新增强制门禁——在干净环境重建嵌入资产后必须与提交内容零差异。

发布二进制（含全部前端资产、strip 后）约 35–40MB；对下游 SILO 服务端而言，内嵌这套控制台的体积代价从约 10MB 降到约 3.5MB。

安全与依赖

Go 侧：构建基线升级到 Go 1.26.5，golang.org/x 系列全部更新至最新。govulncheck 报告的全部可达漏洞已清零：

唯一剩余公告位于 golang.org/x/crypto，官方尚未发布修复且代码路径不可达，作为已知事项记录。

前端侧：生产与开发依赖树的完整审计清零，包括 form-data 的高危 CRLF 注入、DOMPurify 与 qs 的多项公告；React Router 迁移至 7.18.2（保留 v6 兼容的声明式 API，全站路由经过完整回归验证）。唯一被显式豁免的公告仅涉及本项目未使用的 unstable API。

运行时正确性：修复了 HTTP 日志目标在初始化与关闭之间的真实数据竞争，以及测试套件中共享 mock 的竞态；受支持的 Go 包全量通过 -race 检测。作为附带收益，go-m1cpu 升级修复了新版 macOS 上本地 go run 的 cgo 崩溃。

更新检查与默认网络行为

本版本对升级和版本目录功能采取保守默认：

• silo-console update 的自动自更新被禁用，命令只给出提示，不会下载或替换二进制；
• 版本目录新增 SILO_RELEASE_SERVICE_HOST 配置，原有 RELEASE_SERVICE_HOST 作为兼容回退；两者均未设置时不连接任何远端版本服务；
• 帮助面板的 Blog 内容仅在用户打开时按需拉取，跳转链接只接受 https://silo.pgsty.com。

自动更新会在发布资产签名与回滚链路稳定后再重新评估。

发布产物与平台矩阵

正式发布包含 16 个资产：

发布流水线在 tag 推送时触发，工作流的第三方 Action 已固定到具体提交，并在构建前强制执行"干净检出 + 资产重建零差异"门禁。

升级指南

独立二进制

install -m 0755 silo-console-linux-amd64 /usr/local/bin/silo-console
/usr/local/bin/silo-console server

从源码构建时，make console 仍生成 ./console；用于正式服务前按发布名称安装。

DEB/RPM/APK 与 systemd

软件包继续安装 /etc/systemd/system/minio-console.service，单元内部启动 /usr/local/bin/silo-console。EnvironmentFile=/etc/default/console、console-user 与既有 CONSOLE_* 变量不变。这个保留让软件包升级继续作用于原有服务，而不是平行创建一个新服务。

配置与集成

• 不要重命名 CONSOLE_MINIO_SERVER 或 CONSOLE_MINIO_REGION；
• 不要修改 Go import 中的 github.com/minio/console；
• 自建版本目录优先迁移到 SILO_RELEASE_SERVICE_HOST；
• 依赖 console update 的脚本改为显式下载、校验并部署发布资产；
• 按进程路径识别服务的监控更新为 /usr/local/bin/silo-console。

本版本不改变对象数据布局，也不要求对存储桶和对象执行迁移。

验证范围

发布验证覆盖 Go 全包 -race、go vet、golangci-lint、govulncheck、前端类型检查、生产构建、Prettier、死代码检查与完整依赖审计，并执行了以下专项校验：

• 对全部 184 个嵌入文件各发起 gzip 客户端、普通客户端与 HEAD 三种请求，响应体与嵌入源做逐一哈希比对；
• RFC 语义探测（含 gzip;q=0, *;q=0.5 等组合 q 值）、方法限制、OIDC 回调与 SPA 深链；
• React Router 7 全站路由回归：深链、客户端导航、桶详情选项卡切换与浏览器历史后退；
• 移动端首屏侧边栏行为、登录页外部请求监听、明暗主题全站巡回；
• 下载正式发布资产验证校验和逐字节匹配、二进制版本自报一致，并用发布产物直连真实服务端完成冒烟测试；
• macOS 与 Linux 双平台的资产重建零差异验证。

已知限制

• 自动自更新暂时禁用，升级需要显式执行；
• SSO 端到端测试套件依赖外部 OpenLDAP/Dex/MinIO 拓扑，本轮未在该环境中运行（OIDC 代码路径已由单元测试与 HTTP 层验证覆盖）；
• golang.org/x/crypto 存在一条官方尚未发布修复、且代码路径不可达的公告；
• SILO 尚未维护独立的视频资料库，帮助面板中的视频是明确标注的上游兼容性资料；
• 管理能力依赖 MinIO-compatible Admin API，不能把 SILO Console 当作适用于任意 S3 服务的通用浏览器；
• 保留的 Go 模块、环境变量、协议字段和 systemd 服务名仍会在代码、配置和进程管理界面中出现。

关联提交与链接

v2.0.0 的完整变更由以下 8 个逻辑提交构成：

• 50797de — feat: establish SILO Console identity and compatibility
• 23ae6e8 — feat: redesign and harden the SILO Console web app
• 7a83a77 — build: update Go toolchain and dependencies
• 1330d25 — fix: eliminate logger shutdown and test mock races
• 06b3a34 — docs: publish the SILO Console v2.0.0 guide
• 4b24372 — build: regenerate optimized embedded web assets
• c38eb64 — ci: package and publish SILO Console v2 releases
• b952a12 — brand: regenerate the icon set from the official silo.svg emblem

相关链接：

• SILO Console 源代码 · Releases
• SILO 网站 · 文档
• 授权说明 · 来源归属 · 商标说明

2.21 - silo-pkg 3.13.0 正式发布

发布日期： 2026-08-30 · 版本： v3.13.0 · 提交： 215f116 · 仓库： pgsty/silo-pkg

3.13.0 是一个破坏性版本：本模块正式启用独立导入路径 github.com/pgsty/silo-pkg/v3，同时退役 pgsty/silo-go 分支，直接依赖上游 minio-go。维护栈各组件（silo、silo-console 与 mcli）均已在 2026-09-03 / v2.4.0 版本波次完成新路径迁移，详见组件版本矩阵。

版本速览

• 已发布： silo-pkg v3.13.0 标签与 GitHub Release，声明 module github.com/pgsty/silo-pkg/v3。
• 已终结： github.com/minio/pkg/v3 模块身份，以及每个消费者都必须重复一遍的 replace 指令。
• 已终结： github.com/pgsty/silo-go/v7 分支，本版本直接依赖上游 minio-go。
• 未变： 所有包、符号与行为。移动的只是它们被导入的路径。
• 下游接入： 已在 SILO 20260903、Console v2.4.0 与 mcli 20260903 完成同步迁移。

为什么要迁移路径

此前本分支保留上游的 github.com/minio/pkg/v3 路径，以便充当直接替代品——消费者用一条 replace 指令即可选中它。但 Go 不会继承依赖模块声明的 replace，在准备下一个 SILO 服务器版本时，这套安排的三笔账同时到期。

每个消费者都要重复一遍重定向，漏写的那个会静默构建到上游。 一个依赖了本包却没写 replace 的模块，会解析到真正的 minio/pkg，编译通过，然后悄无声息地失去本分支的行为。

require 那行必须写一个源码早已不匹配的版本。 ParseConfigStrict 在上游要到 v3.11.0 才出现，Resource.IsBareARN 则在任何上游版本都不存在。当源码需要 v3.12 的 API，旁边却写着 require github.com/minio/pkg/v3 v3.6.1，这是靠改数字无法变真的元数据。

为此打的补丁还会传播。 pgsty/mc 里有一行纯粹为此存在的编译期哨兵——引用 Resource.IsBareARN——目的是把静默降级变成响亮的构建失败。而把 mc 的下限抬高、让元数据变诚实，又会通过模块图把要求推上去，顶高 silo-console 那条刻意压低的下限——那条下限存在的意义恰恰是防止这件事。

上游路径在这里能提供的回报很少：minio/pkg 是一个小型内部库，而本模块的消费者只有 silo、silo-console 和 mcli。Silo Go SDK 则保留上游的 github.com/minio/minio-go/v7 路径——那里的直接替代能力有真实价值，上游也仍在积极维护。

上游 minio-go 取代 Silo Go SDK

pgsty/silo-go 已经不再包含任何功能性差异。它唯一独有的改动 Return CopyObject checksums in UploadInfo 已于 2026-08-24 合入上游，其余内容只是一个版本字符串、一个 logo、一份 README 和一段 lint 工具声明。

上游最新标签 v7.3.0 比该合并早 14 个提交，其中包括并行分段上传中共享校验和哈希器的数据竞争修复，因此钉住这个标签反而是倒退。本版本改为依赖伪版本 v7.3.1-0.20260828014306-0e78d3f18efe，待上游切出新标签后再换成标签。

兼容性

所有包、导出符号与行为均未改变。本版本移动的是它们被导入的位置，仅此而已。

请与 silo、silo-console、mcli 的配套改动一起采用。单独升级本包的消费者将无法构建——新旧路径是两个不同的模块，类型无法在它们之间传递。

变更前：

require github.com/minio/pkg/v3 v3.6.1

replace (
    github.com/minio/pkg/v3      => github.com/pgsty/silo-pkg/v3 v3.12.2
    github.com/minio/minio-go/v7 => github.com/pgsty/silo-go/v7 v7.3.1
)

变更后：

require github.com/pgsty/silo-pkg/v3 v3.13.0

并把 github.com/minio/pkg/v3/... 的导入改写为 github.com/pgsty/silo-pkg/v3/...。继续沿用旧安排的消费者仍可构建于 v3.12.2 及更早版本之上，这些版本依然可用。

有一个后果值得预期：两条路径现在是不同的模块，因此一次构建里可能同时包含两者——某个第三方依赖若导入 github.com/minio/pkg/v3，它的导入不再被重定向。在 SILO 技术栈中这种情况只出现一次，来自 minio/colorjson 与 minio/dperf，二者都只用到 pkg/v3/console。而该包的颜色开关是 fatih/color 的进程级全局变量 NoColor，所有副本共享同一个，因此关闭颜色仍然会在各处一并生效。

验证

• go build ./...、go vet ./...、go mod tidy -diff、gofmt -l . 全部干净；go test ./... 通过 23 个包。
• 发布提交上的 CI：Go、LDAP Config Validator、VulnCheck。
• 新路径已由一个不带任何 replace 指令的全新模块从模块代理解析成功，导入 policy 并运行通过。
• 下游迁移在发布前已端到端验证：mcli（194 个文件）、silo-console（36 个文件）与 silo（181 个文件）均通过构建、vet 与各自测试套件；silo 的 rebrand guard 通过，兼容基线差异恰为 19 条被删除的导入记录，环境变量、指标、请求头、路由、策略取值与导出符号均无变化。

2.22 - silo-pkg 3.12.0 正式发布

发布日期： 2026-08-24 · 版本： v3.12.0 · 提交： 2b087a1 · 仓库： pgsty/silo-pkg

3.12.0 是直接从主线发布的中版本，包含两条主线：第一，为“只有 ARN 命名空间前缀、却没有指定任何资源”的策略增加严格写入保护；第二，把维护基线推进到 Go 1.27 与 etcd 3.7。它新增两个导出的检查/校验方法，将验证过的消费者下限提高到 Go 1.26；同时也是第一个由 SILO 服务端（eee05a17c，SN-2026-005，随 SILO 20260903 发布）在具名策略与服务账号策略写入路径上启用严格校验的 silo-pkg 版本。

发布状态一览

• 已经发布： silo-pkg v3.12.0 标签、GitHub Release，以及裸 ARN 前缀的严格库级校验。
• 服务端接入： eee05a17c（SILO 20260903）在具名策略与服务账号策略写入路径启用严格校验。
• 刻意保持宽松： 既有 IAM 策略加载、IAM 导入与站点复制接收路径。
• 延后： STS 内联策略严格校验与 Console 客户端侧提前校验；服务端仍是权威边界。

裸 ARN 前缀为何会成为策略哑弹

正常的 S3 资源 ARN 必须在命名空间前缀后指定资源：

arn:aws:s3:::my-bucket
arn:aws:s3:::my-bucket/*
arn:aws:s3:::*

但原策略解析器也接受只有前缀的形式：

arn:aws:s3:::

这个字符串没有指向任何 bucket 或对象。原解析器把它归一到通配资源类型，同时把 arn:aws:s3::: 保留为匹配模式；而真正进入 S3 鉴权的候选资源长成 bucket 或 bucket/object。因此整份策略虽然校验成功，这个模式通常什么也匹配不到。

对真正执行资源匹配的 Statement，实际影响取决于 Effect，以及前缀写在 Resource 还是 NotResource：

危险的两格属于依赖错误策略配置的 fail-open，而不是未认证远程漏洞，也没有 CVE。管理员、策略模板或自动化必须先提交这种错误资源，问题才会出现。同一问题也适用于已经注册的 S3 Tables 与 KMS ARN 前缀。

不操作资源的 Admin Action、sts:* Action Statement，以及 KMS 两阶段鉴权的第一阶段，本来就跳过资源匹配；裸前缀不会改变它们现有的运行时判定。严格写入仍拒绝这个具有误导性的字段，避免策略看起来像“限定了资源”，实际上该范围根本没有参与判定。

历史 *arn:... 形式

在沿用旧版本的宽松兼容路径中，把精确裸前缀解析后重新序列化，仍会在前面带上通配资源类型标记：

arn:aws:s3:::  ->  *arn:aws:s3:::

这两种写法重新解析后得到完全相同的内部资源值。因此 3.12 同时识别精确前缀与历史星号形式。存量/导出策略，以及会在发送前先解析再序列化策略的客户端，都可能出现后者。

原有通配语料保持不变：*、**、***、*foo，以及 arn:aws:s3:::* 这样的显式资源仍按原方式解析。

严格写入，不做存储迁移

修复刻意把“加载已有策略”与“创建新策略”分开：

• ParseConfig 与 Validate 继续宽松；既有存量策略保持相同的加载、匹配与序列化行为。
• ParseConfigStrict 与 ValidateStrict 在 Resource 和 NotResource 中都拒绝“只有已注册 ARN 前缀、没有资源”的形式。
• Resource.IsBareARN() 识别精确/历史形式归一后的值，不改变导出的 Resource 结构、ParseResource、匹配算法或 JSON 表示。
• ResourceSet.ValidateStrict() 向消费者提供严格资源集合校验。

保留原资源表示对混合版本站点很重要：v3.11 与 v3.12 节点仍以相同方式比较、序列化存量策略，因此本修复不会制造站点复制 mismatch，也不要求迁移 IAM 存储。

SILO 在三个边界启用保护

SILO 提交 eee05a17c 选用 silo-pkg v3.12.0，并在以下场景使用严格解析：

1. 创建或替换具名 IAM 策略；
2. 创建带内联 Session Policy 的服务账号；
3. 更新服务账号的内联 Session Policy。

本轮中，以下兼容敏感路径仍保持宽松：

• 加载已经落盘的具名策略与嵌入策略；
• IAM 导入/恢复；
• 站点复制接收与应用；
• STS 内联 Session Policy；
• Bucket Policy——它现有的 bucket/action 校验已经会拒绝这些形式。

启用 ParseConfigStrict 还会激活两条早已存在的 Admin Policy 规则：同一条 Admin Statement 不能同时携带 Resource 与 NotResource；作用于 bucket 的 Admin Action 不能使用非 S3 资源。这些都是刻意的鉴权收紧，已经记录在安全公告台账 SN-2026-005 中。

运维需要做什么

工具不会自动改写存量策略，因为无法推断原作者真正想指定哪个资源。部署包含服务端严格接入的 SILO 构建前，应当：

1. 检查具名 IAM 策略中的精确/历史裸前缀；
2. 检查服务账号的内联策略；
3. 将每一处改成真正想要的具体资源；只有确实想表达整个命名空间时才使用尾部通配符；
4. 所有站点完成滚动升级后再审计一次。

不要机械地把每个命中改成 arn:aws:s3:::*：那可能把原本不起作用的语句变成集群范围的授权或拒绝。含裸前缀的旧策略仍可加载，但不能通过三个严格写入端点原样交回；在修改同一策略或服务账号的其它属性前，必须先纠正该资源。

更安全的审计方式，是使用 policy-info 与 access-key-info API，而不是完整 IAM Export——后者包含普通用户与服务账号的密钥。STS 严格校验继续延后，直到可以单独审计仍在使用的机器客户端及其 Session Policy 模板。

为什么是中版本

本次使用 v3.12.0 而不是 v3.11.1，因为它同时跨越三条兼容边界：

1. etcd 客户端从 3.6 中版本线进入 3.7；
2. 模块验证过的 go 下限从 1.25.0 提高到 1.26.0；
3. 新增了导出的裸 ARN 检查与严格资源集合校验 API。

模块路径仍是 github.com/minio/pkg/v3；/v3 导入后缀与全部现有 import 都无需修改。

Go 与依赖基线

go 与 toolchain 指令承担不同职责：

• go 1.26.0 是选定 etcd 3.7 模块要求的消费者下限。
• toolchain go1.27.0 是维护开发与 CI 基线。
• CI Actions 迁移到 Node 24 runtime。

主要选中版本变化如下：

其它小型更新包括 uax29 2.3.1、fastjson 1.6.10、secp256k1 4.4.1 与 goccy/go-json 0.10.6。旧 lestrrat-go/option v1、gogo/protobuf 与陈旧的测试专用依赖退出选中依赖图。

etcd 3.7.1 是 3.7 版本线上第一个修复 GO-2026-6107 / CVE-2026-73500 的版本；该问题是未经认证即可触发的 TLS listener 拒绝服务。升级这些 Go 客户端模块 不会 自动升级运维使用的外部 etcd 服务端。SILO 不依赖被移除的 grpc.WithBlock 行为，发布验证也实际覆盖了 3.7.1 客户端连接 etcd 3.6.14 服务端。

依赖图声明 coreos/go-systemd 22.7.0，但模块将其 replace 为 22.6.0，因为 22.7.0 无法在 NetBSD 编译。SILO 服务端保留相同的可移植性覆盖。

兼容性

• import 路径与模块主版本不变。
• 既有策略继续按原方式加载和执行；只有严格创建/更新调用会拒绝错误前缀。
• 不执行策略、IAM 数据库、线缆协议或 etcd 数据迁移。
• 在 etcd 客户端拨号选项中使用 grpc.WithBlock 的下游，需要改用受支持的 readiness 检查；SILO 不使用它。
• 真正升级外部 etcd 集群仍是独立运维流程。
• 本分支没有引入上游 AIStor Memory 与新的 AIStor 专属 S3 Tables Action 词汇。

消费者按以下方式选用本版本：

require github.com/minio/pkg/v3 v3.12.0

replace github.com/minio/pkg/v3 => github.com/pgsty/silo-pkg/v3 v3.12.0

验证

已打标签的包通过：

• 仓库完整 make test 门禁：固定版本 lint 加 go test -race -tags kqueue ./...；
• 重复运行裸 ARN 测试，以扰动 Go map 遍历顺序；
• go mod verify、go vet、git diff --check 与 govulncheck，可达漏洞为零。

SILO 接入通过：

• 完整 IAM 服务端套件，包括具名策略精确/历史形式拒绝，以及服务账号创建/更新拒绝；
• go test ./cmd -count=1、go vet ./cmd 与 go test ./...；
• golangci-lint 2.13.1 零问题、go mod verify 与 make check-gen；
• 变异测试证明三个严格调用点与其集成断言都是承重的。

通过 VCS 直接解析模块，确认 v3.12.0 指向提交 2b087a1，模块校验和为：

h1:1Bjqjb3KCt0oYhBLpH7W/e/5khTUoIgXWA12An1fbUc=

Git 标签、GitHub Release、直接模块归档、来源提交与校验和均已验证。

相关变更

• 2bc3a91：CI Actions 迁移到 Node 24
• c8c6872：对齐 SILO Go 依赖栈
• 2b087a1：在严格策略写入中拒绝裸 ARN 前缀；v3.12.0 标签提交
• 30c49bd：标签之后更新 README 依赖示例
• eee05a17c：SILO 启用具名策略与服务账号策略的严格写入
• 56c67dacf：登记 SN-2026-005

服务端发布范围

服务端严格策略写入集成（eee05a17c）已随 SILO 20260903 发布。STS 内联策略的严格校验仍保持延后，以便单独审计机器客户端与会话策略模板。

2.23 - Silo Pkg 3.11.0 发布

发布日期： 2026-08-04 · 版本： v3.11.0 · 提交： d8b1fa7 · 仓库： pgsty/silo-pkg

这是本分支的 第一个定版。它恢复了上游 minio/minio#20449 所报告的 IAM 桶/对象资源边界：策略条件键绕过修复、三个 LDAP 连接缺陷、证书监听器泄漏、有种子 RNG 的缺陷，以及模块真实的最低 Go 版本。

这个仓库是什么

silo-pkg 是 minio/pkg 的维护分支，为社区版 MinIO 分支提供上游（现由闭源产品驱动）不会再接纳的修复。仓库于 2026-08-02 由 pgsty/minio-pkg 改名而来。

模块路径刻意保持不变，仍然是 github.com/minio/pkg/v3，因此所有 import "github.com/minio/pkg/v3/..." 无需改动，只有 replace 指令的右侧需要更新：

replace github.com/minio/pkg/v3 => github.com/pgsty/silo-pkg/v3 v3.11.0

/v3 后缀是模块的主版本号，不是目录名，不可省略。这也正是本次发布编号为 v3.11.0 而非 v4.0.0 的原因：Go 要求标签的主版本必须与 go.mod 中声明的主版本后缀一致，因此在一个 .../v3 模块上打 v4.0.0 会被工具链直接拒绝。真要发布 v4，就必须修改模块路径，并改写服务端、mc 与 Console 中约 395 处 import——那等于放弃"保留上游路径"所换来的直接替换能力，而这正是保持上游路径的意义所在。

IAM 桶/对象边界

每一个桶级 S3 操作，鉴权时对象名都是空的。IAM 匹配器把它拼成资源串，而对空对象名的情况补了一个尾斜杠：

resource.WriteString(args.BucketName)
if args.ObjectName != "" {
    // "bucket/object"
} else {
    resource.WriteByte('/') // "bucket/"  <-- 缺陷所在
}

"bucket/" 会被通配模式 "bucket/*" 命中，因为 * 匹配空串。于是一条把 s3:* 授在 arn:aws:s3:::bucket/* 上的策略——读起来是 “任意操作，但只作用于这个桶里的对象”——也连带授予了桶级操作。在多租户集群里，只持有这条授权的租户可以调用 PutBucketPolicy 装上 {"Principal":"*"}，把桶变成匿名公网可读或可写，或者给自己授予桶级控制权；它也可以直接把桶删掉，而这正是上游 issue 中的复现步骤。

匿名访问所走的桶策略评估路径从来没有这个斜杠，是正确参照。只有 IAM 这条路径错了，而且只错在一个地方。

为何不修正整条边界

对所有桶级请求都不再补斜杠，是显而易见的修法，上游也试过：那次改动当天就因打破依赖旧行为的策略而被回滚。有两个性质让"完整修正"成为一次迁移，而不是一个补丁。

它会撤销真实部署所依赖的授权。 它撤销的不只是危险的桶写入——通过 bucket/* 授予的 ListBucket、GetBucketLocation、ListBucketMultipartUploads 同样会被撤销。证据就是上游自己的测试套件：11 个 STS 集成测试把 s3:ListBucket 授在 bucket/* 上，然后断言列举能成功。连写服务端的项目都这么写，生产策略里只会更多。

它切的是两个方向。 匹配器对 Allow 和 Deny 拼的是同一套资源串，所以删掉斜杠在收紧过度授予的 Allow 的 同时，也放松了过度阻断的 Deny。一个用 Deny s3:* on bucket/* 锁死某个桶的管理员，会悄无声息地失去那层保护。

保护集合是如何确定的

范围由一个问题决定：够到这个动作，能让调用者拿到它的对象级授权本来就给不了的东西吗？

之所以该问这个问题，取决于缺陷的触发条件。资源匹配发生在动作匹配 之后，所以这个 bug 只有在语句本身已经授予了那个桶级动作时才会触发——现实中这意味着 s3:*。因此受影响的主体本就对这个桶里的每个对象拥有完整的读、写、删权限。关键在于：对于一个已经控制桶内全部对象数据的调用者，触及某个桶级动作还会额外赋予什么能力。

不再接受对象级授权的十二个动作：

刻意不予保护，并且有测试对此做出断言——于是把其中任何一个加回去，都是一次带可见代价的明确决定，而不是往列表里添一行：

• PutBucketTagging、PutBucketEncryption、PutBucketNotification。 它们都是桶级写入，早期草案确实纳入过保护。三者都不给调用者任何它还没有的访问权——受损的是所有者的合规姿态，不是访问边界；而一个拿到 s3:* on bucket/*、并被告知"这个桶归你"的租户，完全合理地会去给它打标签、设默认加密、配事件通知。用很低的安全收益去换实打实的兼容成本，在维护版本里是个错误的交易。
• CreateBucket。 它作用于一个还不存在的桶，没有东西可篡改、可摧毁；而供应流程常用租户自己的 bucket/* 凭据去创建租户的桶。
• 读/列举族（ListBucket、GetBucketLocation、各类配置读取）。打破它们正是上游那次完整修复被回滚的原因，它们要等一次带迁移路径的发布。

改动只作用于 Allow 语句。Deny 语句保持历史资源串，因此任何桶级封锁都不会被削弱，NotResource 排除也保持完整覆盖范围。

单调性，以及那个错了两次的论断

上面这一切都建立在一条性质上：这个变更可以收走权限，但绝不能新增权限。 而这条性质被断言过两次，两次都是凭推理而非凭测试，也两次都是错的。把"怎么错的"记录下来，比只记录最终状态更有价值。

第一次尝试让省略的斜杠同样作用在了 NotResource 匹配上——而 NotResource 是 排除。Allow s3:* NotResource bucket/* 这样的语句，历史上不会作用于该桶的桶级请求；把排除拿去和裸桶名匹配，排除就不再命中，于是它所限定的那条 Allow 反而变宽了，而且恰恰是在受保护的那些写入上。

第二次尝试修好了这一处，并在发布时写着结论“可证明地单调”。针对定长通配模式的测试给出了反例。省略斜杠改变了模式所匹配的目标字符串，而一个模式完全可能匹配 "mybucket"，却从来匹配不上 "mybucket/"。定长通配是最直接的例子：

Allow s3:PutBucketPolicy on arn:aws:s3:::mybucke?

? 恰好匹配一个字符。对九字符的 "mybucket/" 它匹配不上，所以这条语句从来没有授予过那个桶级写入；而对八字符的 "mybucket" 它匹配上了，于是这次加固授予了有缺陷的匹配器都拒绝的操作。

在受保护路径上，匹配器现在要求 两种形式同时命中——裸桶名，以及历史的 "bucket/"。结果是与历史判定取交集，因此在构造上就是单调的：不存在任何它能新满足的模式。mybucket* 照旧授予（它本来两种形式都匹配），mybucket/* 照旧被收走，mybucke? 像以前一样被拒绝。

证据

这条性质是被验证的，不是被论证的。我们生成了一份 27000 条鉴权判定 的语料——15 种资源模式 × 3 个桶 × 5 种对象名 × 20 个动作 × 6 种语句形式——分别在加固前基线与本版本上执行，并逐条比对：

那 144 条收窄全部落在设计意图之内，没有一条溢出：动作恰好是受保护的十二个；语句形式只有三种 Allow，Deny、NotResource 排除与 deny-NotResource 三种形式 零变化；资源模式只有四种对象级模式；请求只有桶级请求，对象级请求完全未被触碰。12 × 4 × 3 = 144，严丝合缝。

两个层次都有回归测试。本仓库有十二条匹配器测试钉死每个方向，其中包括一条不变量测试，确保受保护动作个个都是纯桶级动作——ResetBucketReplicationState 名字唬人，实为对象动作，不入集合。服务端有三条端到端测试驱动真实 handler，分别位于客户端、内联会话策略与 S3 路由三个层次；三条在修复前的构建上全部失败，在本版本上全部通过。

需要改什么

只有当你的存量策略把十二个动作之一（或 s3:*）授在含 / 的资源模式上、且同一个桶没有裸桶 ARN 时，你才会受影响。修法是在对象模式旁边补上裸桶 ARN：

"Resource": ["arn:aws:s3:::bucket", "arn:aws:s3:::bucket/*"]

这种配对写法是惯例形式，也是上游自己的测试所采用的写法，在本版本之前同样有效。内置策略不受影响——readwrite、readonly、writeonly、diagnostics 全部使用 Resource: "*"。

MINIO_API_LEGACY_BUCKET_RESOURCE_MATCH=on 在启动时读取一次，可完整恢复历史匹配行为——过度授予与过度阻断两个方向一并恢复。它目前是单一的全局开关，按动作粒度的作用域已列入待办。

策略条件键解析顺序

getValuesByKey() 此前会先按规范 MIME 拼写（http.CanonicalHeaderKey）查找策略条件键，再尝试原始名称。而它读取的那张表里，混放着服务端为当前请求计算出的值（SourceIp、SecureTransport、CurrentTime、username 等，以条件键拼写存储）和请求自带的 HTTP 头（以规范 MIME 拼写存储）。

先查规范拼写，就让客户端的请求头能够覆盖服务端算出来的值。

对 MinIO 服务端而言这是一次策略绕过。最简单的例子是 s3:prefix：一个 Prefix 请求头可以满足家目录前缀条件，而真正的 ?prefix= 查询参数仍然列举整个桶。同一条路径还能触及 aws:SourceIp、aws:SecureTransport、aws:CurrentTime、aws:EpochTime、aws:username、aws:userid、aws:principaltype、aws:UserAgent、aws:groups、ldap:username、ldap:groups、jwt:groups、s3:versionid、s3:signatureversion、s3:signatureAge、s3:authType 与 s3:LocationConstraint。匿名桶策略直接暴露。SigV4 也拦不住，因为客户端可以添加不在 SignedHeaders 列表里的头。

还有第二重后果：当服务端以一种拼写存值、而策略键解析到另一种拼写时，错误的条目会胜出。s3:object-lock-mode 可能解析到调用者的 X-Amz-Object-Lock-Mode 请求头，而不是服务端实际会施加的保留模式。

修复反转了查找顺序：先精确匹配条件键本身的名字，只对确实指代请求头的条件键（例如 s3:x-amz-* 家族）才回退到规范拼写。这移植了 minio/pkg#226，并补上了上游那次改动没有携带的回归测试。

在库的原始映射层面，如果生产者把同一个逻辑字段同时以精确条件名和规范 MIME 名存入，现在精确名胜出。这是一条库层查找规则，不是"查询参数优先"的 S3 线缆协议规则。Silo 服务端会先按真实来源规范化条件值。对于存储类别与上传标签这两处 Header 与查询形式都保持兼容的字段，Header 只要出现就胜出，包括空值，查询参数仅作回退。

LDAP 连接路径

connect() 中的三个缺陷，其中两个由本分支自己在 b0c08a7 中引入，随 v3.6.2 与 v3.6.3 发布。使用这两个版本的用户应尽快升级。

ServerInsecure 开启时 StartTLS 被跳过。 上游把 StartTLS 调用放在只由 ServerStartTLS 控制的外层块里，因此同时开启两个选项时，会先建立明文连接再升级。b0c08a7 把该调用移进了 else 分支，导致只要 ServerInsecure 为真，StartTLS 就不可达。连接保持明文，随后的 bind 就在这条连接上发送了凭据。MinIO 的 MINIO_IDENTITY_LDAP_SERVER_INSECURE 与 MINIO_IDENTITY_LDAP_SERVER_STARTTLS 是独立开关，Validate() 不拒绝任何组合，所以这个状态是可达的。

本版本恢复了上游语义：两个开关是 叠加关系，而非互斥。ServerInsecure 关闭隐式 ldaps://；ServerStartTLS 仍然执行升级。暴露窗口仅限 v3.6.2 与 v3.6.3。

没有 TLS 配置段的 Config 可能在 ldaps:// 路径上 panic。 l.TLS.Clone() 移出 StartTLS 分支之后，普通 ldaps:// 连接也会调用它。Clone() 对 nil 接收者返回 nil，而下一行却给 ServerName 赋值。MinIO 服务端总会提供 TLS 设置，但这是一个库，mc 同样在消费它。现在代码会回退到空的 tls.Config，与 DialURL 本来会构造的一致。

StartTLS 没有超时。 go-ldap 只在 requestTimeout > 0 时才启动请求计时器，而 StartTLS 本身没有超时。一台完成了 TCP 建连、随后对扩展请求不再响应的服务器，可以让连接 goroutine 永久挂住。现在计时器在 StartTLS 之前就已武装。

StartTLS 失败会泄漏连接。 这一条继承自上游。拨号失败不会返回连接，因此 StartTLS 失败是 connect() 里唯一可能同时返回连接与错误的路径。调用方只在错误为 nil 时接管所有权，于是对一台升级功能损坏的服务器，每次登录尝试都会遗留一个 socket。失败路径现在会关闭连接并返回 nil。

其它修复

• certs：文件监听器从未被停止。 Manager.AddCertificate() 注册了两个 notify.Watch() 却一个都不停：如果第二个失败，第一个就泄漏；而且两个都会在 manager 关闭后一直存活到进程退出。Certificate.Watch() 与 watchFile() 有同样的问题。四条路径现在统一使用 watchDirSafe()，它返回一个在出错与 ctx.Done() 时被调用的停止函数。这移植了 minio/pkg#228 的 certs/ 部分。在 Windows 上该函数用轮询替代文件系统通知，而不是把轮询仅作为失败回退，因此证书重载可能滞后一个 symlinkReloadInterval（10 秒）。本分支没有 Windows CI，该平台仅做了交叉编译。
• rng：reader 的子密钥取自一个被清零的局部变量。 init() 把 32 字节熵读进 r.tmp，却从一个同名的、已清零的局部变量派生出四个子密钥，把四条按块划分的流坍缩成了一条。随后 Reset() 与 ResetSize() 会逐字节重放上一条流。MinIO 每次 randreader.New() 都创建新的 reader 且从不 reset，因此实际服务端影响有限；这个缺陷是 warp 暴露出来的。这移植了 minio/pkg#230。
• xtime：Duration 实现了 UnmarshalJSON 却没有 MarshalJSON。 编码产出的是纳秒整数，而解码无条件剥掉首尾各一个字节并期待带引号的字符串，两个方向都无法往返。现在它使用 time.Duration 的字符串形式编码。这移植了 minio/pkg#242。

兼容性影响

• 十二个桶级写操作不再能通过对象级资源模式获得授权。 见需要改什么。对象访问、ListBucket、CreateBucket、桶标签、默认加密与事件通知均不受影响，Deny 语句与 NotResource 排除同样不受影响。
• 最低 Go 版本从 1.26.1 降回 1.25.0。 go 指令里的补丁号对每一个消费者都是硬性下限，而不是构建该模块所用工具链的记录。惯例做法是 go 行写语言版本、单独的 toolchain 行写开发版本。1.25.0 才是依赖图实际要求的版本，也是上游声明的版本。CI 会在 GOTOOLCHAIN=local 下用 Go 1.25 构建完整测试套件，因此这个下限是被证明的，而不是宣称的。
• xtime.Duration 的 JSON 线缆格式变更，从纳秒整数改为 "2h"、"30m" 这样的时长字符串。已持久化的数值形式无法再读回。在 MinIO 与 mc 中未发现此类用法：批处理作业定义以 YAML 持久化，msgp 路径仍为 int64。
• 同时开启 ServerInsecure 与 ServerStartTLS、且 LDAP 服务器不支持 StartTLS 的部署，在 v3.6.2/v3.6.3 上会以明文成功连接，现在则连接失败。这是正确结果，但它暴露在连接阶段而非配置校验阶段。对这类服务器请关闭 ServerStartTLS。
• Policy.IsAllowedActions 对那十二个受保护动作可能与直接判定不一致。 它遍历 SupportedActions，其中包含 s3:* 这个模式本身，因此返回的集合可能包含 s3:*——从而看起来允许某个受保护动作——而直接求值却是拒绝。服务端没有任何地方调用它，Console 调用时传的是空桶名，永远走不到加固分支。此处选择记录而非修改：在维护版本里改变一个公开 API 的输出，风险更大。

与上游 v3.11.0 的差异

版本号跟随上游的线，不声称内容一致。以 policy/ 下的动作字符串常量为口径，实测差异如下：

有 24 个动作只存在于上游： 6 个 s3:*ObjectAnnotation*、5 个 admin: 动作（DistJobStatus、Get/SetBucketCompression、两个 TablesReplication*），以及 13 个覆盖函数 CRUD 与打标签的 s3tables: 动作。它们属于本分支刻意不采纳的 AIStor 词表，因为社区版服务端并不实现这些功能。

有 3 个动作在两侧名称不同。 上游对它们做了改名与拆分，本分支保留较早的名称：

因此，一条写了这六个动作名之一的策略，在两者之间 只有一个 能通过校验。Silo 服务端、mc 与 Console 都没有引用它们，所以在本生态内没有影响；但从上游 v3.11.0 切换过来的消费者应当知道，动作词表并不可互换。

rng 没有 arm64 汇编。 上游在本分支分叉点之后加入了 rng/xor_arm64.{go,s}，本版本在 arm64 上回退到纯 Go 的 xor_noasm.go 路径。结果正确、交叉编译干净，但在该架构上比上游慢。它是未来同步的一个干净候选：纯性能改动，不牵涉词表分歧。

服务端配套行为

• 本版本的条件键改动 必须 与服务端"保留内部条件键名、按语义来源填充取值"的改动配对，见文首提示。
• s3:signatureAge 只有在 SigV4 预签名请求校验器算出它之后才会暴露。在其它任何请求类型上，客户端提供的 x-amz-signature-age 头都会被忽略。
• s3:prefix、s3:delimiter、s3:max-keys 只来自查询参数。内容哈希、拷贝源、元数据指令、SSE 与对象锁条件只来自对应的请求头。校验预签名请求时消费的 X-Amz-Content-Sha256 查询值不会成为策略条件。
• s3:x-amz-storage-class 保留其兼容的查询形式，PutObject 与 CreateMultipartUpload 上的请求标签同样保留。这两个字段都是 Header 出现即胜出，只有 Header 缺失时才使用查询参数。
• s3:ExistingObjectTag/* 只来自从已存储对象加载的标签，因此请求自带的 X-Amz-Tagging 不能再冒充既有对象状态。PutObject、CreateMultipartUpload 与 PutObjectTagging 把 s3:RequestObjectTag/* 绑定到这些 handler 实际消费的标签输入。其余动作路径出于兼容保留了历史的 X-Amz-Tagging 头回退，因此只在 API 确实消费标签的地方，才把请求标签条件当作约束使用。
• aws:SourceIp 由转发头计算得出。它是否可强制执行，取决于服务端的可信代理配置；参见服务端自己关于 MINIO_API_TRUSTED_PROXIES 的发布说明。

验证

以下全部在打标签的那个提交上执行，工作树干净，标签与 HEAD 一致：

• make test——golangci-lint 加 go test -race -tags kqueue ./...，全部包通过。
• go mod tidy -diff 干净；gofmt -l 为空；go vet ./... 干净。
• linux/amd64、linux/arm64、darwin/arm64、windows/amd64 四个组合的交叉编译。
• govulncheck ./...——零个可达漏洞。仅剩一条模块级提示 GO-2026-5932（x/crypto/openpgp）：该包已停止维护、没有修复版本，且本仓库并未 import 它。
• 从空模块缓存经公共 proxy 解析，确认发布出去的版本确实可获取。
• 上文所述的 27000 条鉴权判定语料。

依赖与工具链

依赖更新清除了 govulncheck 此前报告的九项 可达 问题：经 sftp 触达的七个 x/crypto/ssh 问题、经 etcd 触达的 gRPC GO-2026-6061，以及经 oidc 触达的 go-jose GO-2026-4945。

有五个依赖——minio-go、minio/mux、etcd client/v3、go-oidc、lestrrat-go/jwx——刻意未升级。MinIO 通过 replace 消费本模块，而最小版本选择会取整个依赖图中的最高版本，因此在这里升级它们会连带把服务端也拽着往前走。这五个都没有必须升级的已报告漏洞。

三个工作流此前都向 setup-go 索要低于 go.mod 要求的 Go 版本，并在第一条 Go 命令上失败，现已对齐。linter 此前还从 master 分支拉取安装脚本并每次重装；URL 与版本现已固定到 v2.11.3，且当已安装版本匹配时会跳过下载。

刻意未采纳的上游改动

• AIStor 策略词表（Memory/cortex、Tables/Iceberg、KMS、压缩与注解）以及带类型的动作常量重构，社区版服务端均不实现。这也是动作词表差异的来源。
• securityAuditAdmin：它授予 admin:ExportIAM，因而会暴露每一个密钥，与名字给人的印象相反。
• rng 的 AVX2/NEON 汇编。其中 arm64 那一半已在上文列为未来同步候选。
• net.BandwidthBytesPerSec（上游声明了却从未读取）、replicationAdmin 与 DistJobStatusAction。
• 两项先采纳、复核后又移除的改动：consolereadonly 内置策略与 GetAllGlobalCertificates，两者都没有消费者。一旦运维把内置策略名绑定到用户身上，再撤回就格外危险：策略映射按名字持久化，而无法解析的名字会并入一个拒绝一切的空策略；它继承的 admin:CreateUser Deny 也无法与 iamAdmin 组合使用。那个证书辅助函数清点的是社区版服务端从不填充的缓存。
• 上游的 golangci-lint tool 指令，它会给每个下游消费者的模块图增加约 200 个 linter 依赖。

刻意推迟的部分

minio/minio#20449 的一般性问题——bucket/* 仍会触及 ListBucket、GetBucketLocation、各类配置读取、CreateBucket 以及上述三个租户可能合理使用的写入——在这里 没有 被关闭。彻底关掉它意味着撤销真实部署所依赖的授权，因此它属于一次带迁移路径的发布。

那次发布欠运维的东西，比"一份更长的动作清单"要多，因为没有人能穷举所有部署的存量策略——这给"靠猜来划定保护集合"的做法设了一个硬上限。有三件事能抬高它：

• 启动时的策略审计：遍历存量策略，逐条点名哪一条的含义会改变，授予与拒绝两个方向都点。它是只读的，甚至可以 先于 强制生效单独发布，从而把"升级后的意外"变成"升级前的清单"。
• 会自我解释的拒绝：当一个请求因为"只有对象级授权匹配上"而被拒时，就把这句话说出来，并点名那个兼容开关。一次 30 秒能自诊断的破坏，成本比静默破坏低一个数量级。
• 带作用域的开关：MINIO_API_LEGACY_BUCKET_RESOURCE_MATCH 今天是全有全无，只想要回一个动作的运维，被迫连自我提权那条路一起重新打开。

相关提交

• d8b1fa7：fix(policy): settle the bucket-write hardening’s scope and monotonicity
• 1f97549：fix(policy): extend the bucket-write hardening to every bucket-only write
• 3c24ad1：fix(policy): withhold object-only grants from sensitive bucket writes
• da6a22a：docs: say what this fork is and how to depend on it
• 4055b2f：fix(xtime): marshal Duration as a duration string
• 13c26cd：fix(rng): initialize the reader subkeys from the seeded entropy
• 88b37ac：fix(certs): stop file watchers on every exit path
• 74dd36e：fix(ldap): keep StartTLS when ServerInsecure is also set
• 424c3d0：fix(ldap): close the connection when StartTLS fails
• 045d10f：fix(ldap): guard a nil TLS config and arm the StartTLS deadline
• 5c4bf50：fix(policy): prefer the exact key name over the canonical header form
• 802539f：chore(deps): refresh the dependency set and declare the real minimum Go
• e4ec64a：ci: build on the Go version go.mod requires, and prove the declared minimum
• 747d8b8：build: pin the golangci-lint installer and skip a matching install

2.24 - Silo 20260903 正式发布

版本日期： 2026-09-03 · 正式发布： 2026-09-04 · 版本： RELEASE.2026-09-03T13-18-01Z · 上一版本： RELEASE.2026-08-06T00-00-00Z

SILO 20260903 是首个完整使用 Silo 品牌的版本之后的一次安全与正确性发布，重点收紧核心服务端不变量：客户端 header 不能凭空获得复制权限；浏览器 Origin 不能在鉴权前触发桶元数据 I/O；并发桶配置写入不能彼此静默覆盖；授权与校验和行为进一步对齐 AWS S3。

本文以 20260806 为基线，汇总 2026-09-03 交付的服务端、Console、共享包与客户端完整变更。后续修复（包括 SN-2026-011）已分别随 SILO 20260916、SILO 20261015 与 SILO 20261018 发布。

亮点

• 复制信任来自授权。 X-Minio-Source-Replication-Request 与相关内部字段只有在签名验证、精确 marker 校验以及 s3:ReplicateObject / s3:ReplicateDelete 授权后才获得复制语义。不可信字段在鉴权后清洗，因此不会破坏 SigV4。
• 桶级 CORS 完整落地。 PUT、GET、DELETE ?cors 持久化真实桶策略，覆盖服务端全局 fallback，并通过站点复制收敛。预鉴权查找只读驻留元数据；启动期与已知元数据加载失败状态都保持 fail-closed。
• 桶元数据更新串行化。 共享 metadata.lock 覆盖所有整记录配置写入、迁移、导入、站点 adoption 与 healing。ForceCreate 不再擦除既有配置；存在 Object Lock 文档的桶始终使用纯 Enabled 版本控制。
• 授权与请求动作一致。 显式删除版本需要 s3:DeleteObjectVersion；用户和组的启用/禁用按目标状态检查对应 action；策略写入拒绝空的 ARN namespace。
• 校验和进一步对齐 AWS S3。 UploadPart 可由服务端计算校验和；联邦 UploadPartCopy 返回校验和；multipart completion 返回 ChecksumType；非法断言使用 AWS 兼容错误；CRC64NVME 与 COMPOSITE 的无效组合被拒绝。
• SSE-C 读取与复制统一校验密钥。 零字节对象和 GetObjectAttributes 不再绕过密钥认证；null-version 改写与原地换钥不会再留下不可读密文或不一致的 checksum metadata。
• 发布前主动减法。 删除死代码与过期 lint 例外；兼容快照只追踪真实对外服务面；依赖锁定到已审 revision；timeout 测试改用私有随机源。
• 客户端版本归入同一基线。 mcli 20260903 新增只读 checksum verify，完成 fail-closed 凭据脱敏，修复 Metrics JSON 与 S3 Select，严格校验策略写入，并提供签名软件包、溯源证明与验证过的 amd64/arm64 镜像。

安全修复

仓库安全台账为五个没有 CVE 的发现分配了稳定的本地编号。SN- 不是 CVE。完整威胁模型、兼容影响与运维动作集中记录在 SILO 20260903 安全说明。

五个缺陷都继承自已归档的上游服务端代码，影响此前所有 SILO 版本。SN-2026-008 是对 CVE-2026-34204 接收端全链路修复的补全。

内嵌 Console v2.3.0 线还包含可信代理边界、TLS 校验修复、响应与日志脱敏、WebSocket 转发上限。

S3 正确性与互操作

Multipart 校验和

本版本关闭了 #46、#47、#48、#50 报告的 multipart 互操作问题组：

• 客户端在创建上传时选择算法、但没有为每个 part 提供 checksum header 时，UploadPart 由服务端计算所选校验和；
• 旧版联邦后端的 UploadPartCopy 不再丢掉远端返回的 checksum；
• CompleteMultipartUpload 返回 ChecksumType，缺失、畸形、矛盾或不支持的 checksum 使用 AWS 兼容错误；
• 未知算法以及无效的 CRC64NVME + COMPOSITE 组合直接拒绝，不再静默 canonicalize。