文章

• 1: SILO 一年回顾：相比上游 MinIO，我们到底干了什么？
• 2: 续命 MinIO：承诺兑现
• 3: MinIO 已死，MinIO 复生
• 4: MinIO已死，谁能接盘？
• 5: MinIO已死

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。

路还长，我们继续维护。

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 出来的时候，老冯还在。

就这样。

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 协议变更的思考。

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 阉割的控制台能力。

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 阉割的控制台能力。