SILO 20261015 Release Notes

Tag: RELEASE.2026-10-15T00-00-00Z · Package version: 20261015000000.0.0. Use the download page for binaries, Linux packages and Docker instructions.

This is the first Server release containing the complete SN-2026-015 and SN-2026-016 Object Lock repairs from PR #234 and PR #235. Server 20260916 and the earlier tested Server 20260903 are affected; no earlier SILO release contains these repairs. Upgrade every Server process and every replication site that accepts S3 writes.

Selected source: 7a3ca0f82100cce06289a465f54139da2639f642.

Published: 2026-10-15 13:52:28 (UTC+8). The 36 published GitHub assets match the accepted files; the checksum manifest is available without authentication.

The release includes the merged changes since Server 20260916, whose source is 2a4d51406b7e. See the complete source comparison.

Object Lock repairs

• SN-2026-015 — retention authorization: every PutObjectRetention request requires s3:PutObjectRetention, evaluated with request-body condition keys before reading object state. Shortening or removing active GOVERNANCE retention, or changing its mode additionally requires the explicit bypass header and s3:BypassGovernanceRetention. A bypass grant no longer overrides a retention Deny. Removal evaluates remaining retention as zero days; distant future dates no longer saturate the calculation.
• SN-2026-016 — protected version writes: caller-selected write version IDs require trusted replication. Directory null versions and persisted multipart targets are checked under the destination write lock before overwrite, including uploads started before upgrading or recovered from older staging state. Existing GOVERNANCE, COMPLIANCE and legal-hold protection applies at the actual write. Lock-state read failures reject the operation.
• Release prerequisite: PR #237 makes the release workflow reuse the existing Object Lock race regression suite. A failed regression blocks artifact publication. The suite includes slow-body directory overwrites, preflight read failures, legacy multipart completion against COMPLIANCE and recovered-upload UUID collisions.

See the security advisory for affected behavior and the repair design for regression boundaries and trade-offs.

Other changes since 20260916

Build tooling also updates golangci-lint for Go 1.27.2. The release does not rewrite historical metadata, recover overwritten content or reconstruct old retention settings.

Component identities

Console, mcli and pkg retain their existing released identities. Updating those components alone does not repair an installed Server. The supported administration stack is the coordinated PGSTY stack; compatibility with unmodified upstream MinIO/MC remains best effort.

Upgrade requirements

1. Upgrade every Server process and all replication sites that accept S3 writes. A fixed site does not reauthorize a retention change already accepted by an unpatched peer. Mixed deployments remain exposed through their old writers.
2. Review policies that used bypass without s3:PutObjectRetention, or relied on bypass to evade retention conditions. They now fail with 403 AccessDenied. Keeping or extending GOVERNANCE with the base permission remains supported.
3. Ordinary S3 writes cannot choose a target versionId, including requests signed by root. Use normal version-creating writes. Trusted replication retains version IDs; mcli batch replicate to SILO requires s3:ReplicateObject on the target credentials.
4. Locked directory objects and existing locked multipart targets cannot be overwritten. If lock metadata cannot be read, restore storage health before retrying; a read failure does not authorize an overwrite.
5. Review prior audit records for unexpected retention changes and check data affected before the upgrade. The fix prevents new bypasses; it does not undo accepted changes. When upgrading from releases before 20260916, also follow the September upgrade requirements.

Artifact acceptance

The following checks passed against the released source 7a3ca0f82100cce06289a465f54139da2639f642:

All 36 release assets were downloaded and verified. 34 artifact attestations bind their covered files to the exact tagged source. Static identity checks confirmed the tag and commit in all six Linux/macOS/Windows amd64/arm64 binaries. The six RPM/DEB/APK packages contain the matching Linux binary and expected supporting files; both RPM signatures passed verification. Compare downloads with the archive and SBOM checksums and package checksums.

The actual macOS arm64 release binary passed 110/110 runtime and upgrade checks:

Across those runs, 65 rejected operations left the complete checked object state unchanged. These runtime results cover macOS arm64. Windows and macOS amd64 binaries were not executed; their verification was static. Linux runtime results are recorded below.

Docker images

Docker publication run 38689158028 passed for the same release source. Both images are anonymously accessible from Docker Hub and contain linux/amd64 and linux/arm64 manifests.

At publication, latest matched the classic version digest and distroless matched the distroless version digest. Independent OCI attestation verification passed for both exact index digests, binding them to the release tag, source 7a3ca0f82100cce06289a465f54139da2639f642 and the GitHub-hosted docker-release.yml workflow.

Each of the four platform manifests was pulled by its exact digest and passed the same Object Lock API suite:

The /usr/bin/silo copied from each container is byte-for-byte identical to the corresponding official Linux archive binary. All four actual endpoints returned HTTP 200 for /minio/health/ready. The image suite passed 196/196 checks; 120 rejected operations returned the exact expected HTTP/S3 error and preserved the checked object content, version identity, ETag, size, modification time, retention, legal hold, user metadata and full version listing.

Together with the native installation and same-data upgrade checks, runtime acceptance passed 306 checks with zero failures. These results cover the environments listed above; they do not establish that an operator’s production deployment has been upgraded.