Component Versions

Verified on 2026-09-16. SILO releases its four components independently. A merged dependency update does not change an existing binary or image.

Published components

Release notes: Server 20260903, Console v2.4.1, mcli 20260916, pkg v3.14.1. For embedded deployments, select Console and MC explicitly in the Server build. Package-repository mirrors may lag GitHub; the download page links directly to the published artifacts.

September 16 dependency graph

Console v2.4.1 selects the released pkg and MC sources below. These identities are verified through the public Go proxy and checksum database.

• Console: v0.0.0-20260916075814-1360e26d976d → 1360e26d976d, tag v2.4.1.
• pkg: v3.14.1 → fa657ef431ae22e720df37e5144cf00f67102945.
• MC: v0.0.0-20260916070421-e952aa78f10a → e952aa78f10a, tag RELEASE.2026-09-16T00-00-00Z.
• Upstream minio-go: v7.3.1-0.20260915093545-32e1f32cb176.
• JWX / strfmt / React Router: v3.3.0 / v0.27.2 / v7.18.4.

Console’s embedded frontend is rebuilt from this graph. Its Go dependency uses the canonical pseudo-version because the historical module path has no /v2 suffix. Server embedders must copy both Console and MC replacements; see the Console integration notes.

Review the password-permission migration before upgrading: admin:ChangeMyPassword and admin:CreateUser now express separate operations. The Server changelog and source links below describe the storage, IAM and HTTP changes needed for coordinated Server upgrades.

Storage, IAM and HTTP repairs

The following changes have merged into Server main. They remain absent from the published Server 20260903; use the linked PRs and source records to identify a build containing them.

Upgrade and compatibility requirements:

• IAM requires a coordinated upgrade of all participating servers. Mixed old/new nodes sharing an IAM backend and rolling downgrade are unsupported. Back up complete IAM storage and required encryption material; a live admin export omits deletion history. Older credentials for a recreated parent may need reissuance. Pre-upgrade deletions whose history is already lost cannot be reconstructed automatically. Follow the IAM upgrade and rollback guide.
• Unavailable pools can now fail writes and deletes more consistently. Conditional multipart completion fails if any pool’s metadata is unreadable, even when GET/HEAD can use another pool. Ordinary version DELETE also fails on unreadable pools or cleanup errors; insufficient read quorum returns 503 SlowDownRead. Retry after recovery. Successful deletion does not promise immediate removal from every drive while outbound delete replication is pending.
• Access-frequency pool tiering was never in Server 20260903. Only builds containing the experimental feature need its configuration/XML migration. Ordinary lifecycle expiration, remote-tier transitions, rebalance and decommission remain available.
• Purge audit status is normalized from COMPLETE to COMPLETED. Malformed historical tag revisions can fail and retry; this repair does not reconstruct their history. A shorter header timeout also constrains TLS handshake reads; this is not a new total-duration limit for HTTP/1 uploads or downloads.
• Objects with recorded tag revisions take one extra metadata COPY per object during explicit resync or heal; when the destination is KMS-encrypted by bucket default, that copy rewrites the object data. Replication rules with tag filters still evaluate target eligibility against the post-deletion (empty) tagging state, and arbitrary site clock skew remains outside the repaired ordering guarantees. Both endpoints of a replication pair must run the repaired build for tombstones to be honored; an old peer still drops empty-value revisions. See Replicated Tag Ordering.

The R4–R8 integration record contains source hashes, local tests and remaining acceptance limits. PR #196’s 11 checks passed before merge. Those results establish source acceptance, not a new release or production cluster rollout.

Console shared downloads

Console #56 and Server #209 resolve the anonymous proxy boundary reported in Console #52. The proxy only accepts object-content GETs at the configured S3 origin and rejects redirects, system paths and query-selected non-download operations. No sharing-disable environment variable was added. Normal public, presigned and versioned downloads remain supported; see the behavior and design tradeoffs.

The fix is released in Console v2.4.1. The exact release source passed the complete CI matrix, vulnerability checks and release workflow. Real API and browser sharing tests passed in standalone and embedded deployments; the downloaded standalone binary also passed the sharing regression against a SILO fixture.

Ordinary conditional PUT

The separate cross-pool conditional PUT defect in #199 was reproduced on published Server 20260903. PR #207 was merged as 9b4ae82a29cc after its head 4620be394b52 passed all eight CI checks on 2026-09-16. The repair is on main and remains unreleased. Its behavior is:

• Ordinary multi-pool If-Match / If-None-Match conditions use the logical current object across all pools. Unreadable metadata can prevent acceptance even when GET still works from another pool; read-quorum failures return 503. Restore readability or heal before retrying.
• When a destination versionId is supplied, the public condition still compares the current object. The requested destination version is preserved; internal replication keeps its addressed-version checks. Unconditional PUT and single-pool conditions retain their existing behavior.
• A successful conditional overwrite does not retire stale copies in other pools, and upgrading cannot recover historical accepted overwrites. Existing modification-time/pool ordering remains in use; this adds no global clock ordering guarantee.

The multipart-completion fix in #190 neither introduced nor repaired this PUT defect. Final packaged-candidate and rollout acceptance remain tracked in #203.

Work still pending

• Upgrade and historical-state readiness: #200 tracks the IAM upgrade/restore rehearsal; #201 tracks historical replica inventory and repair validation. Source repairs do not automatically repair old state.
• Release delivery: #202 collects release notes and component identities; #203 separately validates final artifacts and multi-process behavior. No new Server release is established by these tracking issues.
• Multipart listing: #79 remains open for capacity/release acceptance and the known delayed-creation-write boundary. PR #198 repairs durable discovery, global pagination and static cancellation confirmation; it does not add a creation fence or certify large-scale scanning. The temporary 10,000-upload trial missed the provisional five-second page target; see the design record.

Dependency and release order

1. Verify the upstream SDK commit and required fixes. Keep the upstream github.com/minio/minio-go/v7 path; the retired silo-go fork is not part of the maintained graph.
2. Validate and publish pkg under github.com/pgsty/silo-pkg/v3, including its migration notes. Resolve the tag through the Go proxy and checksum database.
3. Update MC to that pkg and SDK, validate it, then publish the calendar-tagged mcli release. Go consumers select its canonical pseudo-version.
4. Update Console’s direct pkg requirement and explicit MC replacement, validate its embedded frontend and integration, and publish Console when a release is intended. An accepted immutable source commit can also be selected explicitly.
5. Update Server’s direct pkg/SDK requirements and both PGSTY replacements, client archive hashes, image and Helm client pins. Validate the complete graph before a separate Server release, image publication and cluster rollout.

Go does not inherit a dependency module’s replace directives. Server must explicitly select both maintained Console and MC even when Console already selects MC. Console and MC retain their historical MinIO module paths; pkg uses its own path directly. Legacy transitive minio/pkg/v3 from colorjson/dperf is separate from the maintained policy implementation.

The main stack uses Go 1.27.1; pkg retains a Go 1.26 library floor and was also race-tested with Go 1.26.8. The Go x/* dependencies were refreshed. The effective go-systemd version stays v22.6.0 because v22.7.0 fails to compile on NetBSD; Console’s tablewriter v0.0.5 replacement preserves its MC API. These are documented compatibility pins, not missed automatic upgrades.

Other dependencies change for concrete CVE/bug fixes, not just newer major versions. The September 13 Go scans found no reachable or imported vulnerable package, but retained module-only GO-2026-5932 in unused OpenPGP code. A clean reachability result is not a claim that every selected module is advisory-free.

The supported integration target is the coordinated PGSTY stack. Compatibility with unmodified upstream MinIO/MC and other S3 implementations is best effort.