SILO 20261015 发布说明
标签： RELEASE.2026-10-15T00-00-00Z · 包版本： 20261015000000.0.0。二进制、Linux 安装包与 Docker 安装方式见下载页。
这是首个包含 PR #234 与 PR #235 对 SN-2026-015 与 SN-2026-016 对象锁问题完整修复的 Server 正式版本。Server 20260916 和此前实测的 Server 20260903 均受影响；更早的 SILO 发行版均未包含这些修复。请升级全部 Server 进程及所有接受 S3 写入的复制站点。
选定源码： 7a3ca0f82100cce06289a465f54139da2639f642。
发布时间： 2026-10-15 13:52:28（北京时间）。公开的 36 个 GitHub 制品与已验收文件一致，校验和清单可匿名下载。
本版包含 Server 20260916（源码 2a4d51406b7e）之后合入的改动，详见完整源码差异。
对象锁修复
- SN-2026-015 — 保留期授权： 每个
PutObjectRetention请求都必须获得s3:PutObjectRetention授权，在读取对象状态前使用请求体条件键求值。缩短、清除未到期 GOVERNANCE 保留期，或改变其模式，还必须同时具备明确的 bypass 请求头与s3:BypassGovernanceRetention权限。bypass 授权不能覆盖 retention Deny。清除保留期按剩余零天求值，远期日期计算不再饱和。 - SN-2026-016 — 保护已有版本： 客户端指定写入版本 ID 必须具备复制信任。目录
null版本与持久化分片目标在实际覆写前、持有目标写锁时复查，覆盖升级前创建或从旧暂存状态恢复的分片上传。已有 GOVERNANCE、COMPLIANCE 与 Legal Hold 保护在实际写入时生效。锁状态读取失败即拒绝操作。 - 发行前置门禁： PR #237 让发行工作流复用现有 Object Lock race 回归，测试失败会阻止发布制品。回归覆盖慢请求体目录覆写、预检读取失败、旧分片完成覆写 COMPLIANCE，以及恢复上传 UUID 碰撞。
20260916 以来的其他改动
| 改动 | 用户可见效果 |
|---|---|
| #233 | 复用旧版 xl.meta 头部时清除缺失字段，使扫描更新与最终响应互斥。存储格式与 RPC 字段不变，见验证记录。 |
| #225 | 对齐 S3 校验和错误文案，包括 Content-MD5 拼写。 |
| #220 | 修复 Lambda 目标集合判空逻辑，并新增空集合与非空集合的回归测试。 |
fa565ec9f |
使用 Go 1.27.2 与 golang.org/x/net v0.60.0 构建，同步模块要求、依赖检查与固定 digest 的 Docker 构建阶段。 |
构建工具同时更新 golangci-lint，以支持 Go 1.27.2。本版不会重写历史元数据、恢复已覆写内容或重建此前的保留期设置。
组件身份
| 组件 | 选用版本 |
|---|---|
| Server | RELEASE.2026-10-15T00-00-00Z；包版本 20261015000000.0.0 |
| 内嵌 Console | v2.4.1，源码 1360e26d976d |
| mcli | RELEASE.2026-09-16T00-00-00Z，源码 e952aa78f10a |
| 公共包 | github.com/pgsty/silo-pkg/v3 v3.14.1 |
| 上游 S3 SDK | github.com/minio/minio-go/v7 v7.3.1-0.20260915093545-32e1f32cb176 |
| 工具链 | Go 1.27.2 |
Console、mcli 与 pkg 沿用既有正式版本。只更新这些组件不能修复已安装的 Server。正式支持的管理组合是协调后的 PGSTY 栈，与未修改的上游 MinIO/MC 保持尽力兼容。
升级要求
- 升级全部 Server 进程，以及所有接受 S3 写入的复制站点。已修复站点不会重新授权未修复对端已经接受的保留期变更；混合版本部署仍通过旧写入节点暴露风险。
- 检查仅授权 bypass、未授权
s3:PutObjectRetention，或依赖 bypass 绕过 retention 条件的策略。此类请求现在返回403 AccessDenied；持有基础权限时仍可保持或延长 GOVERNANCE 保留期。 - 普通 S3 写入不能指定目标
versionId，root 签名请求也一样。请使用正常的新版本写入。可信复制仍保留版本 ID；mcli batch replicate写入 SILO 时，目标凭据需具备s3:ReplicateObject。 - 已锁定的目录对象与已有分片目标不能被覆写。若锁元数据不可读，请先恢复存储健康再重试；读取失败不能作为放行覆写的依据。
- 排查升级前的审计记录中是否存在意外保留期变更，并核对此前可能受影响的数据。修复阻止新的绕过，不会撤销已接受的变更。从 20260916 之前的版本升级时，还需遵循九月版升级要求。
制品验收
以下检查均针对已发布源码 7a3ca0f82100cce06289a465f54139da2639f642 通过：
| 检查 | 结果 | 证据 |
|---|---|---|
| 主分支 Go CI | 通过 | 运行 38686240587 |
| 漏洞检查 | 通过 | 运行 38686240625 |
| 发行构建与 Object Lock 前置门禁 | 通过 | 运行 38686425467 |
| 发行软件包定稿 | 通过 | 运行 38687734395 |
已完整下载并核验 36 个发行制品，34 份制品来源证明将覆盖的文件绑定到准确的标签源码。Linux、macOS、Windows 的 amd64/arm64 共六个平台二进制均通过标签与提交的静态身份检查；六个 RPM/DEB/APK 安装包中的 Linux 二进制及配套文件与预期一致，两个 RPM 签名均验证通过。下载后可核对归档与 SBOM 校验和以及安装包校验和。
实际发布的 macOS arm64 二进制通过 110/110 项运行与升级验收：
| 场景 | 通过 |
|---|---|
| 全新安装，完整 Object Lock API 验收 | 49/49 |
| 使用官方 20260916 二进制创建的数据进行原地升级 | 12/12 |
| 升级后再次运行完整 API 验收 | 49/49 |
其中 65 次被拒绝的操作均未改变所检查的完整对象状态。这些运行结果覆盖 macOS arm64。Windows 与 macOS amd64 二进制未做运行测试，已完成的是静态身份核验；Linux 运行结果见下文。
Docker 镜像
Docker 发布工作流 38689158028 在相同发行源码上通过。两个镜像均可从 Docker Hub 匿名访问，均包含 linux/amd64 与 linux/arm64 manifest。
| 镜像 | 版本标签 | 多平台 index digest |
|---|---|---|
| Classic | RELEASE.2026-10-15T00-00-00Z |
sha256:aaac6bce13eb99316b3c88bd20143fc3c38ab607585256a411a095c44ee57f62 |
| Distroless | RELEASE.2026-10-15T00-00-00Z-distroless |
sha256:70cac541c5a928be5cd16d6b8732d85ac06e891a0e3d9956a745381330692fc6 |
发布时，latest 与 classic 版本 digest 相同，distroless 与 distroless 版本 digest 相同。两个准确 index digest 的独立 OCI 来源证明验证均通过，将其绑定到发行标签、源码 7a3ca0f82100cce06289a465f54139da2639f642 与 GitHub-hosted docker-release.yml 工作流。
四个平台 manifest 均按准确 digest 拉取，并通过相同的 Object Lock API 验收：
| 镜像 | 运行环境 | API 验收 | 二进制字节 |
|---|---|---|---|
| Classic linux/arm64 | Docker Desktop ARM64 上原生 ARM64 | 49/49 | 与官方 Linux arm64 归档一致 |
| Classic linux/amd64 | Docker Desktop ARM64 上仿真 AMD64 | 49/49 | 与官方 Linux amd64 归档一致 |
| Distroless linux/arm64 | Docker Desktop ARM64 上原生 ARM64 | 49/49 | 与官方 Linux arm64 归档一致 |
| Distroless linux/amd64 | Docker Desktop ARM64 上仿真 AMD64 | 49/49 | 与官方 Linux amd64 归档一致 |
从四个容器复制出的 /usr/bin/silo 均与对应官方 Linux 归档中的二进制逐字节一致。四个实际服务端点的 /minio/health/ready 均返回 HTTP 200。镜像验收 196/196 项通过；其中 120 次被拒绝的操作均返回准确的预期 HTTP/S3 错误，且所检查的对象内容、版本身份、ETag、大小、修改时间、保留期、Legal Hold、用户元数据与完整版本列表均未改变。
加上原生安装与同数据升级验证，运行验收合计 306 项通过，零失败。这些结果覆盖上表所列环境，不代表运维人员的生产部署已经完成升级。