SILO 20261018 Release Notes

Server 20261018 is available with versioned archives, native packages, and standard/distroless Docker Hub images for amd64 and arm64. It supersedes Server 20260916 (20261015 is retained as a superseded historical draft record).

See the download page for versioned archives, native packages, and pinned container commands.

Object Lock and IAM security

SN-2026-015 / SN-2026-016 — Object Lock retention authorization and in-place overwrite protection. #234 and #235 repair retention authorization and in-place overwrites:

• Every PutObjectRetention request evaluates s3:PutObjectRetention with the request’s Object Lock condition keys before looking up the target object. Shortening, clearing, or changing the mode of an active GOVERNANCE retention additionally requires both x-amz-bypass-governance-retention: true and s3:BypassGovernanceRetention (which supplements rather than replaces s3:PutObjectRetention). Clearing retention evaluates remaining retention days as 0, and active COMPLIANCE retention cannot be shortened or changed.
• Caller-selected write versionId parameters require trusted replication credentials (s3:ReplicateObject). Directory null versions and persisted multipart targets are re-verified under the destination write lock, and unreadable retention metadata fails closed while preserving existing legal holds. Upgrade all writing nodes and every replication site accepting S3 requests. See the security advisory and repair design.

SN-2026-017 — Admin credential self-service authorization. #242 ensures credential self-inspection and cleanup respect explicit Deny statements, session-policy restrictions (sessionPolicy), and external authorization plugin decisions. Under built-in authorization, restricted session credentials cannot create or update service accounts broader than their own scope, and non-root administrators cannot mutate root’s derived credentials; unrestricted empty-policy inheritance and cleanup of damaged non-root keys remain supported. Follow-up commit 995439260 normalizes bulk self-listing aliases to the parent identity and preserves self-inspection for ordinary users without attached policies, requiring no new Admin actions or IAM storage migration. See the security note and authorization contract.

Scoped STS revocation

0cd388c66 updates RevokeTokens to enumerate durable STS identity records alongside in-memory caches, allowing nodes that missed an earlier token-issuance notification to revoke matching tokens reliably. Committed token tombstones are broadcast to sibling nodes and site-replication peers even if another token in the batch fails to save, and offline peers converge via IAM deletion healing. Object-backed and etcd-backed cache refreshes also evict revoked tokens after missed notifications or watches.

The revocation scope remains the requested parent identity and optional token type across the cluster’s snapshot prior to the operation cutoff, leaving newly issued tokens, unrelated users, and parent policies untouched. Durable enumeration adds work only to the administrative revocation path, not to per-request authentication. See the STS revocation design and cost analysis.

Rebalance and pool decommission consistency

60c7179dd (incorporating #248) and 1748f62c7 prevent rebalance and pool-decommission workflows from overwriting a newer object copy in another pool with an older migrated copy. Migration re-verifies source versions (including multipart completions and tiered-object metadata) under the shared object lock, preserves null and UUID delete markers, and removes only confirmed migrated versions rather than deleting the entire source prefix. Concurrent writes, deletes, or destination changes safely abort cleanup for a later retry.

Before retiring a pool, verify object versions, tags, and delete-marker state as described in multi-pool object consistency (independent cross-site delete-marker ordering remains tracked in #217).

Ordinary object listing recovery

#239 (incorporating the original #221 work and closing #218) fixes an issue where ListObjects / ListObjectsV2 could succeed while omitting readable keys during eligible cross-pool metadata disagreements. The pool merger now re-verifies uncertain same-name entry groups under the corresponding object read locks: it returns current readable metadata, omits confirmed absent keys, or returns an explicit error such as 503 SlowDownRead when quorum cannot establish either state. A failed pagination producer fails the scan; clients must consume all pages and treat any page error as an incomplete listing.

Resolved entries retain their lock-free fast path. Recovery applies only to eligible latest-object groups without lowering quorum or adding persistent metadata; request cancellation interrupts lock backoff, and identified recovery lock conflicts wait for a single bounded interval. Follow-up commits 3dd53eb81 and 2080b3d03 preserve directory and CommonPrefixes entries when a colliding object name is confirmed absent. Measured latency and lock-cost benchmarks are documented in listing recovery lock cost.

Multipart upload listing and cleanup

Default disk scan rolled back to legacy in-memory listing. The default disk-scan implementation merged on October 17 (#243) was withdrawn by 4733e1423. Public ListMultipartUploads uses the node-local in-memory cache when prefix is empty and performs an exact-key lookup when prefix is nonempty; process restarts or requests routed to different nodes can omit in-flight uploads (scalable persistent enumeration remains tracked in #79).

Compared with 20260916, MINIO_API_MULTIPART_LISTING=strict is retired: setting the environment variable logs a startup warning and is ignored (the legacy shared api multipart_listing config key is likewise tolerated and ignored). However, the 20260916 upload-creation identity metadata, uploadId path validation, abort target matching, and post-abort cache/peer notifications remain active. The read-only multipart-preflight Admin diagnostic still requires admin:StorageInfo and reports mode=legacy, applying its entry, timeout, and concurrency budgets strictly to explicit diagnostic calls. See the multipart listing design, rollback rationale, and capacity benchmarks and the configuration reference.

Background stale-upload cleanup (default 24-hour expiry checked every 6 hours) includes two repairs:

• #236 parses native upload-directory timestamps before falling back to Base64 decoding, avoiding unnecessary disk metadata reads.
• 0f9199e0c removes empty upload-parent directories immediately after deleting expired child upload directories, rather than waiting another 24-hour cycle after child deletion updates the parent’s mtime (nonempty parents and active uploads remain protected).

Error classification, metadata reuse, and smaller repairs

Coordinated components and dependencies

Standalone Console v2.4.2 and mcli 20261018 declare silo-pkg v3.14.2, while Server’s module graph selects v3.14.3 (which optimizes admin-action classification without altering authorization semantics) and explicitly requires the maintained Console and MC modules.

minio-go v7.4.1 adds failed-upload cancellation cleanup, UTC retention timestamps, and preserved STS durations. Dependency updates include go-jose v4.1.6, ldap v3.4.15, compress v1.20.3, msgp v1.6.5, etcd v3.7.2, and golang.org/x/*. Note: go-jose v4.1.6 rejects OIDC/JWK RSA keys larger than 4096 bits; verify OIDC discovery, JWKS, and login flows before upgrading if your identity provider uses oversized RSA keys (see the dependency security note).

Release tooling pins GoReleaser v2.18.3, nFPM v2.48.0, golangci-lint v2.15.0, and govulncheck v1.9.0, with Object Lock race regressions gating release builds. make rebrand-guard now uses git grep and reports read errors explicitly without requiring ripgrep (7007c164a). Because the bundled Helm chart still defaults to the 20260916 Server image tag, override the image tag explicitly when deploying 20261018 via Helm.

Upgrade and rollback checklist

1. Back up state and pin artifacts: record your installed versions and pin verified binary or image digests. Follow the migration guide and IAM recovery procedure to back up complete IAM storage, configuration, and encryption keys (standard live IAM exports omit revocation tombstones).
2. Coordinate cluster cutover: upgrade all Server nodes and replication sites together; do not mix old and new binaries against the same IAM backend or perform rolling cross-version downgrades.
3. Verify Object Lock and service-account policies: test retention updates, legal holds, service-account creation/updates, explicit self Deny rules, and root credential management with the exact credentials used by your automation. Reissue previously damaged expiring keys through an authorized parent identity.
4. Remove strict multipart listing dependencies: if MINIO_API_MULTIPART_LISTING=strict was enabled on 20260916, ensure clients track their own active bucket/key/UploadID tuples for completion or cancellation rather than relying on public ListMultipartUploads for full discovery.
5. Check listing, retry handling, and OIDC/TLS paths: verify ordinary and paginated LIST, client retry policies for 503 SlowDownWrite on PUT/completion, OIDC/JWKS RSA key sizes, and outbound connections across TLS-inspecting middleboxes (see the Go 1.27 TLS and OIDC guide).
6. Rollback considerations: downgrading to 20260916 reintroduces the October Object Lock and admin credential vulnerabilities, and upgrading does not retroactively restore versions or tags overwritten prior to the upgrade.

Artifact verification and acceptance record

The signed tag RELEASE.2026-10-18T00-00-00Z and all 36 release assets build from 0cd388c666f8211f552604ae73448a066e9c25ce and passed Go CI, VulnCheck, Release, and package finalization.

• Static artifact verification: verified all asset digests, 6 archive version stamps, 6 native package payloads (RPM/DEB/APK), 34 build provenance attestations, 2 Sigstore checksum signatures, 2 RPM package signatures, and 12 SBOMs.
• Functional and fault-recovery acceptance: exercised native Darwin and Linux S3/IAM/STS/Object Lock suites, LDAP/OIDC, in-place upgrade from 20260916, bucket and site replication, 3-site recovery with Console, 3-site and 4-process shared-cluster STS revocation, and 4 multi-pool migration scenarios (2/3 pools × rebalance/decommission). An 8-process, 2-pool cluster completed 2,896 full listing scans under rolling restarts and 1,270 full listing scans under fault-recovery load with zero missing keys, duplicates, or corrupted reads; 3 Linux package lifecycle suites and 8 container runtime variants also passed (Windows and Darwin amd64 artifacts were verified statically, and amd64 containers ran under emulation).
• Published Docker Hub digests:
  • Standard image (and latest at publication): sha256:2636fc4155d9a7e41ff58cdb65ddd13ba9304e67184e13c25bc5cb34016269d7
  • Distroless image: sha256:472f59c7be537571f0f9a2ee6b8fe033a220939d521255bd4bf5339e53db7218

Thanks to szopi00 for reporting the Object Lock issues; mr javad seydi (@mrjavadseydi) for the initial LIST and multipart work; Julien Laurenceau (@julienlau) for the commit-metadata classification and struct-reuse fixes; clown15 for upload-directory cleanup; cbornet and yupoet for checksum error message improvements; AleksaMCode for the Lambda target-set fix; and Denis Babchuk (@botdeniska) for the #248 migration overwrite fix and silo-pkg optimization.