PGSTY SILO Blog

• 1: Posts
  • 1.1: SILO at One Year: What Actually Changed Since Upstream MinIO?
  • 1.2: MinIO Fork, Promise Kept
  • 1.3: MinIO Is Dead, Long Live MinIO
  • 1.4: MinIO Is Dead. Which Next?
  • 1.5: MinIO is Dead
• 2: Release Notes
  • 2.1: SILO 20261026: Server, mcli and KES
  • 2.2: SILO 20261018 Release Notes
  • 2.3: silo-pkg 3.14.3 Released
  • 2.4: PGSTY KES 20261018 Released
  • 2.5: SILO Console 2.4.2 Released
  • 2.6: mcli 20261018 Released
  • 2.7: silo-pkg 3.14.2 Released
  • 2.8: SILO 20261015: Superseded Draft Record
  • 2.9: SILO Console 2.4.1 Released
  • 2.10: silo-pkg 3.14.1 Released
  • 2.11: SILO 20260916 Release Notes
  • 2.12: mcli 20260916 Released
  • 2.13: mcli 20260913 Released
  • 2.14: silo-pkg 3.14.0 Released
  • 2.15: SILO Console 2.4.0 Released
  • 2.16: Silo Console 2.2.0 Release Notes
  • 2.17: SILO Console 2.5: Interface and Administration Updates
  • 2.18: silo-pkg 3.15: Go 1.27.3 and S3 SDK Fixes
  • 2.19: Silo Console 2.1.0 Released
  • 2.20: Silo Console 2.0.0 Released
  • 2.21: silo-pkg 3.13.0 Released
  • 2.22: silo-pkg 3.12.0 Released
  • 2.23: Silo Pkg 3.11.0 Released
  • 2.24: Silo 20260903 Released
  • 2.25: Explicit Version Deletes Now Require DeleteObjectVersion
  • 2.26: mcli 20260903 Released
  • 2.27: mcli 20260806 Released
  • 2.28: Silo 20260806 Released
  • 2.29: Silo 20260804 Released
  • 2.30: mcli 20260804 Released
  • 2.31: Silo 20260618 Released
  • 2.32: Silo 20260417 Released
  • 2.33: Silo 20260325 Released
  • 2.34: Silo 20260321 Released
  • 2.35: Silo 20260314 Released
  • 2.36: Silo 20260214 Released
  • 2.37: Silo 20251203 Released
• 3: SILO Security Chronicle
  • 3.1: October Security Update: Object Lock, Admin Credentials and JWK Parsing
  • 3.2: SN-2026-015 & SN-2026-016: S3 Object Lock Governance Retention Bypass and Version-Addressed Overwrites
  • 3.3: September Security Repairs: Payload Integrity, IAM Revocation and Console Sharing
  • 3.4: SN-2026-011: Fix and Release Status
  • 3.5: CVE-2025-62506: Session-Policy Privilege Escalation
  • 3.6: SILO 20260903 Security Notes: SN-2026-006 through 010
  • 3.7: CVE-2026-32285: The jsonparser Advisory That Required No Patch
  • 3.8: CVE-2026-33322: OIDC JWT Algorithm Confusion
  • 3.9: CVE-2026-33419: LDAP STS Enumeration and the Throttling Chain
  • 3.10: CVE-2026-34204: Replication Metadata Injection
  • 3.11: CVE-2026-39414: Oversized S3 Select Records and a SIMD Bypass
  • 3.12: CVE-2026-40344: Snowball Auto-Extract Authentication Bypass
  • 3.13: CVE-2026-41145: Unsigned-Trailer Query Authentication Bypass
  • 3.14: CVE-2026-42600: ReadMultiple Storage-REST Path Traversal
  • 3.15: SN-2026-002: Internode Path Containment Audit — Paying Off What CVE-2026-42600 Left Owing
  • 3.16: SN-2026-003: s3:versionid Condition Evaluation and Request Condition Hardening
  • 3.17: SN-2026-004: Object-Scoped Policy Grants Reaching Bucket Mutations
  • 3.18: SN-2026-018: Client Source Address Trust, Forwarded Headers, and aws:SourceIp
  • 3.19: SN-2026-019: Notification Keyspace Registration and Validation Redaction
  • 3.20: Duplicate Part Numbers in CompleteMultipartUpload
• 4: Design Records
  • 4.1: SILO, KES and OpenBao: Key Ownership and Recovery
  • 4.2: Pinned TLS Parameters and Handshake Compatibility
  • 4.3: Bucket Configuration Replication: Source Times, Deletions, and Deterministic Convergence
  • 4.4: SigV4 Signed-Header Coverage: Rejecting Unsigned x-amz-* Headers
  • 4.5: Durable IAM Revocations
  • 4.6: Federated CopyObject: Preserve the Destination Contract
  • 4.7: Multi-Pool Object Consistency
  • 4.8: Object Lock Replication Ordering
  • 4.9: SSE-C Replica Integrity
  • 4.10: Replication Reliability: Delete Completion, MRF Visibility, and Resync Cancellation
  • 4.11: FULL_OBJECT Checksum Replication: Preserve the Type at Upload Initiation
  • 4.12: IAM Policy Reloads: Lock Scope, Cancellation, and Time Budgets
  • 4.13: LDAP Long DNs: Restoring Login Without Hiding Revocation Errors
  • 4.14: Replicated Tag Ordering: Revision Timestamps, Tombstones, and Resurrection
  • 4.15: SILO Server 20260903 Pre-release Review
  • 4.16: Overwrite Pool Affinity: Why #245 Was Not Adopted
  • 4.17: Replica Metadata Normalization: What a Trusted Copy May Not Re-Inject
  • 4.18: Request-Header Deadlines: Absolute Header Limits and Rolling Body Idle Timeouts
  • 4.19: Conditional DELETE: One Condition, One Logical Object
  • 4.20: DSN-Only Database Notifications: A Compatibility Boundary for #53
  • 4.21: Preview Text, Never Execute It: SILO Console Text Preview Design
  • 4.22: Multi-Pool Deletion: Preserve the Latest Copy on Failure
  • 4.23: Go 1.27 TLS Defaults and OIDC Discovery Failure Modes
  • 4.24: No I/O Before Auth, No Privilege From Headers
  • 4.25: One Endpoint, Two Privileges: Separating User and Group Status
  • 4.26: IAM Admin API Authorization Boundaries
  • 4.27: Config Environment Files Are Not Shell Scripts
  • 4.28: Two SSE-C Keys, One CopyObject Response
  • 4.29: ListMultipartUploads Behavior and Design Trade-Offs
  • 4.30: Why CompleteMultipartUpload Must Return ChecksumType: Review of PR #57
  • 4.31: When the Total Is Unknown: Folder Download Progress
  • 4.32: A Listing Must Not Drop a Null Version That Still Has Quorum
  • 4.33: A ListObjects Shortcut Must Not Turn a Missing Bucket into an Empty One
  • 4.34: Read-Only Checksum Audit and Reliable CLI Output
  • 4.35: Optional Checksums, Mandatory Failure: Repairing UploadPart and UploadPartCopy Compatibility
  • 4.36: BadDigest, InvalidRequest, and the CompleteMultipartUpload Checksum Contract
  • 4.37: Clearing Stale Fields in Legacy Metadata and Scanner Responses
  • 4.38: LIST Recovery: Confirm Only Uncertain Names and Bound the Waiting Cost
  • 4.39: Object Lock Retention Bypass and Version-Overwrite Repair Design (SN-2026-015 / SN-2026-016)

1 - Posts

Essays and analysis about MinIO, S3-compatible object storage, and the SILO community fork.

1.1 - SILO at One Year: What Actually Changed Since Upstream MinIO?

On October 15, 2025, MinIO shipped its final public open-source release, RELEASE.2025-10-15T17-29-55Z (commit 9e49d5e7a648). Over the next four months, upstream placed the repository into “maintenance mode,” deleted the minio/console repository outright, and in February 2026 archived the main server repository—routing all subsequent CVE patches and bug fixes exclusively to its commercial AIStor product.

On October 26, 2026, SILO tagged RELEASE.2026-10-26T00-00-00Z (commit c3ad836aed0d). Across 376 days, the server repository accumulated 604 commits, evolving alongside its companion repositories silo-console, mcli, and silo-pkg.

A question we hear often from operators evaluating the fork is straightforward: Over the past year, did SILO merely rebrand the binary and apply surface-level CVE patches, or did it fix substantive storage and protocol bugs? Compared with the final upstream MinIO release, what actually changed?

Here is the short answer: SILO preserved MinIO’s erasure-coding storage layout (xl.meta v1.3), HighwayHash bitrot protection, and fundamental read/write quorum rules, while focusing a full year of engineering on security boundaries, S3 protocol and checksum correctness, replication and lifecycle convergence, failed-write rollback and multi-pool safety, and a restored administration console and CLI.

Equally important are the boundaries that have not changed:

1. No distributed fencing, and no claim that every consistency problem is solved. Late commits after lease expiration or network partitions remain possible; strict generation read refusal, automatic cross-pool read recovery, public persistent ListMultipartUploads scanning (#79), access-frequency pool tiering, and multi-pool overwrite affinity (#245) were tested and withdrawn or deferred when their capacity or availability costs proved unacceptable.
2. No head-to-head full-cluster throughput benchmark between the two tags. We record targeted microbenchmarks and amortized overhead checks, not synthetic cluster-wide throughput claims.
3. On-disk compatibility does not mean arbitrary mixed-version operation or rolling downgrade. Durable IAM revocations (siloParentRevocation) and replication metadata tombstones require coordinated upgrades across participating nodes.

The sections below walk through each area in detail, with exact commit references, design records, and operational boundaries.

1. Baseline and Product Stack: What Changed and What Stayed the Same

Our comparison uses two fixed points:

• Upstream baseline: minio/minio RELEASE.2025-10-15T17-29-55Z (commit 9e49d5e7a648f00e26f2246f4dc28e6b07f8c84a, October 15, 2025). Note: between that final release and archiving the repo in February 2026, upstream merged 9 unreleased commits (such as POST policy tag constraints in fa18589d1c and conditional PUT read-quorum adjustments in 18f97e70b1), which never shipped in an upstream release and were addressed independently in SILO.
• SILO target: pgsty/silo RELEASE.2026-10-26T00-00-00Z (commit c3ad836aed0d8a7d23c2e44a5eaa3009d08525e3), released alongside mcli / KES 20261026, Console v2.5.1, and silo-pkg v3.15.2. See the release notes and component matrix.

Across 9e49d5e7a648..c3ad836aed0d, pgsty/silo contains 604 reachable commits spanning feature and security repairs, regression suites, packaging, and documentation. The sections below organize those changes by delivered runtime behavior.

The Four-Component Coordinated Stack

Because the server embeds the Console frontend and imports mc administration packages alongside shared policy and encryption libraries, maintaining the server alone is not enough. SILO maintains a coordinated four-component product graph (plus optional external KES):

Foundations Intentionally Preserved

So existing MinIO deployments can switch to pgsty/silo in place without data migration or client changes, SILO keeps the core storage and wire contracts unchanged:

• Erasure coding and bitrot protection: Reed-Solomon erasure coding and per-block HighwayHash256 verification remain unchanged.
• Read and write quorum rules: Read quorum remains $K$ (data shards); write quorum remains $K$ when data and parity shard counts differ, and $K+1$ when data shards equal parity shards (for example, 16-drive 12+4 uses R12/W12, while 8+8 uses R8/W9).
• On-disk format and system namespace: xl.meta stays at version 1.3 and .minio.sys retains its layout, allowing existing drives to mount directly.
• Wire and configuration compatibility: MINIO_*, MC_*, and CONSOLE_* environment variables, /minio/health/* probes, /minio/v2/metrics/* and /minio/metrics/v3 scrape endpoints, and X-Minio-* headers remain supported (see the compatibility overview and migration guide).

2. Security, Authentication, and Authorization: 7 CVEs and 18 Security Boundary Hardenings

Because SILO retains the github.com/minio/minio Go module path while upstream advisories publish open-ended affected version ranges, automated scanners frequently flag SILO for every historical MinIO CVE.

To separate fact from scanner noise: vulnerabilities such as CVE-2025-62506 (service-account privilege escalation), CVE-2025-31489, and CVE-2025-27414 were already fixed in upstream’s 2025-10-15 baseline. By contrast, the 7 CVEs below were disclosed after 2025-10-15, left unpatched in upstream open-source MinIO, and fixed and verified in SILO:

18 SN-2026-* Security Boundary Hardenings

Beyond public CVEs, adversarial code review and multi-node testing uncovered 18 additional security boundary defects tracked in our Security Advisories ledger:

1. SigV4 SignedHeaders Integrity and Policy Condition Isolation (SN-2026-011, SN-2026-003):
   • Upstream allowed callers to attach unsigned X-Amz-* operational headers (such as governance bypass, tagging, or checksum headers) to an otherwise valid SigV4 request. SILO requires every X-Amz-* operational header present on the request to be covered by SignedHeaders.
   • Upstream populated IAM policy condition maps directly from client headers and query parameters, allowing callers to spoof server-authoritative condition keys such as s3:prefix, s3:versionid, s3:ExistingObjectTag/*, or aws:PrincipalType. SILO isolates server-authoritative condition keys in silo-pkg and binds s3:VersionId checks to the actual target version in DeleteObjects and GetObject.
2. Bucket-Level Write Boundaries, Version-Deletion Authorization, and Admin Action Splits (SN-2026-004, SN-2026-005, SN-2026-009 and 010, SN-2026-017):
   • Tightened resource ARN matching for 12 bucket-level write actions (s3:CreateBucket, s3:DeleteBucket, s3:PutBucketPolicy, s3:PutLifecycleConfiguration, etc.) so object wildcard grants (arn:aws:s3:::bucket/*) or bare arn:aws:s3::: ARNs cannot mutate bucket configurations.
   • Require s3:DeleteObjectVersion for permanent deletion of an explicit version ID, including null; an ordinary delete that creates a delete marker still uses s3:DeleteObject. Batch deletion checks each entry independently.
   • Split user status toggling out of admin:CreateUser into admin:EnableUser / admin:DisableUser; separated self-service password changes into admin:ChangeMyPassword (see password-permission migration); and enforced parent-account ownership checks across IAM admin access-key creation, inspection, and listing endpoints.
3. Service-Account Delegation Ceilings and Object Lock Governance Bypass (SN-2026-015 and 016):
   • Fixed inline session-policy evaluation so parent Deny rules are never dropped when the inline policy omits a matching Allow, and re-verified live parent privileges on temporary STS and service-account sessions.
   • Required x-amz-bypass-governance-retention: true when PutObject overwrites a GOVERNANCE-locked object, and validated retention XML payloads before evaluating Object Lock governance bypass in PutObjectRetention.
4. Durable IAM Revocations, Policy Reload Lock Isolation, and LDAP Long DNs (SN-2026-013):
   • Previously, in multi-node and site-replicated clusters, delayed site-replication events or missed peer notifications could resurrect deleted users, policies, or service accounts. SILO persists deletion tombstones, revision numbers, and parent revocation cutoffs (siloParentRevocation) across both object-backed IAM and STS enumeration, and reloads committed state on peer delete notifications.
   • Moved slow IAM policy loads and KMS decryption outside the hot authentication-cache lock while propagating KMS request cancellation (design record); fixed LDAP StartTLS precedence and hex-escaped long DN path-component limits (design record).

3. S3 Protocol Completeness and End-to-End Checksums

On the S3 protocol surface, SILO focused on three goals: implementing stubbed-out bucket APIs, aligning multi-pool conditional write semantics, and ensuring end-to-end plaintext checksum and size accuracy across multipart, encrypted, and compressed objects.

4. Replication and Lifecycle Correctness

In clusters running active-active replication or remote tiering, the most damaging bugs are silent divergence between sites or premature deletion of tiered data. Over the past year, SILO fixed six replication and lifecycle failure modes:

SILO also isolated per-job and per-target cancellation contexts and fixed ReplicatedCount / FailedCount accounting in replication resync (Replication Resync Correctness), and added per-bucket locks plus optional field-level tombstones (MINIO_SITE_REPLICATION_METADATA_TOMBSTONES) for bucket configuration convergence (Bucket Metadata Convergence).

5. Storage Mutation, Rollback, and Multi-Pool Safety

In an erasure-coded storage engine, the happy path is straightforward; edge-case bugs hide at the intersection of slow drives, partial-write rollbacks, concurrent overwrites, and multi-pool scaling. The 20261026 release ships three groups of storage-layer safeguards:

1. Commit Error Classification and Overwrite Rollback RPC Forwarding

• Missing staging xl.meta classified as 503 SlowDownWrite: When a slow drive or concurrent cleanup causes a staging xl.meta file in .minio.sys/tmp to go missing during commit, SILO classifies the condition as errFileNotFound and returns HTTP 503 SlowDownWrite so clients can retry safely instead of receiving a false 404 ObjectNotFound (error classification design).
• Overwrite rollback option forwarding and timeout boundaries: SILO forwards storage RPC deletion options (including the previous data directory needed for overwrite rollback) while preserving existing drive/RPC deadlines, request cancellation, object locking, read quorum, and healing rules. Note that a client-visible timeout does not mean underlying disk or RPC I/O has stopped or that the write failed to commit—late commits or delayed UndoWrite calls can still occur after partial failures, lease loss, or network partitions (the admitted-I/O draining waits and per-drive mutation guards explored in the October maintenance draft were withdrawn in dcc2f20ba; see the final maintenance boundaries).

2. Multi-Pool Locking, Two-Stage Bulk Deletion, and Migration Safety

For multi-pool deployments:

• Shared cross-pool namespace locks: Fixed pool-local lock isolation where concurrent writes, deletes, and metadata updates on different pools failed to serialize against one another.
• Two-stage multi-pool deletion (#257): Previously, multi-pool DeleteObjects issued parallel deletes across all pools; if the pool holding the newest version succeeded while a pool holding an older copy failed due to a drive error, the stale copy resurfaced as the current object. SILO now deletes in two stages—cleaning non-authoritative duplicate pools first and removing the authoritative copy only after stale copies are gone, while protecting referenced remote tier objects on partial failure (Multi-Pool Delete Safety).
• Rebalance and decommission safeguards: Preserved object tags and revision timestamps across pool migration and prevented decommission from overwriting newer versions or dropping delete markers on the destination pool (Multi-Pool Object Consistency).

3. LIST Recovery Under Drive Disagreement (#239)

During rolling restarts with concurrent overwrites, minority drive disagreements or unresolved entries could cause ListObjects to omit readable keys. While keeping the lock-free fast path intact, SILO now confirms eligible unresolved latest-object entries on demand, distinguishes real deletions from drive read errors, and propagates terminal errors through pagination (LIST Recovery Design Record).

6. Restoring the Full Control Plane: SILO Console v2.5.1 and mcli 20261026

For day-to-day operators, the most visible difference between SILO and upstream MinIO is the administration control plane.

SILO Console v2.5.1: From a Stripped Browser Back to a Full Admin Console

In mid-2025, upstream stripped the embedded community Console down to v1.7.7—removing cluster administration, IAM, policies, lifecycle, replication, diagnostics, and monitoring panels to leave only a bare object browser—and subsequently deleted github.com/minio/console.

Building on the community restoration initiated by Georg Mangold (@gmangold), SILO shipped six major Console releases (v2.0.0 through v2.5.1), restoring the full administration suite while making the frontend smaller, faster, and telemetry-free:

Console 2.5.1 also fixes group membership during status changes, OIDC group permissions, TLS-proxy session cookies, credential exports and keyboard focus. See the Console 2.5 series notes.

mcli 20261026: Honest Exit Codes and Read-Only Checksum Verification

On the client side, pgsty/mc ships as mcli (while preserving MC_* environment variables and ~/.mc / ~/.silo configuration compatibility) and fixes long-standing CLI reliability gaps:

• Read-only mcli checksum verify: Verifies end-to-end FULL_OBJECT checksums across buckets, prefixes, or object versions directly against the server without mutating objects or writing local files, supporting --versions, --Algo, and --json.
• Nonzero exit codes on partial or permission failures:
  • mcli admin info --json now exits nonzero when access is denied or a node reports status: error (upstream exited 0);
  • mcli mirror, mcli mv, mcli retention, mcli legalhold, and mcli sql all return nonzero exit codes on partial object failures, source-deletion errors, or permission denials;
  • Downloads interrupted mid-stream fail immediately rather than reporting a truncated file as complete.
• Safe mirror delete propagation and --dry-run restarts: Prevented mirror --remove from deleting destination objects when source listing fails; added --dry-run to mcli admin service restart; and honored optional persisted region settings in alias configurations.

The 20261026 client also isolates cached identities, drains resync JSON through terminal states, fixes rate overflow, returns nonzero for partially failed start/cancel operations, and adds batch pending output with bounded fallback when live metrics are missing. See the mcli changes and script migration notes.

7. Operations, Configuration, and Supply-Chain Delivery

Across server operations and artifact delivery, SILO made four practical changes:

1. Enforced request-header timeouts and trusted-proxy boundaries:
   • Upstream defined --read-header-timeout / MINIO_READ_HEADER_TIMEOUT without wiring it into http.Server, leaving HTTP/1 connections vulnerable to slowloris-style trickle headers. SILO wired the setting into the HTTP server with a 30-second absolute HTTP/1 header deadline (design record).
   • Added MINIO_API_TRUSTED_PROXIES and MINIO_IDENTITY_LDAP_STS_TRUSTED_PROXIES so X-Forwarded-For is never trusted blindly by default; added CONSOLE_WS_MAX_MESSAGE_BYTES and CONSOLE_WS_MAX_DECOMPRESSED_BYTES to bound embedded Console WebSocket frames.
   • Added a native silo healthcheck subcommand for shell-free distroless containers and tightened MINIO_CONFIG_ENV_FILE parsing to reject malformed lines.
2. Hardened event notification targets:
   • Fixed NATS reconnect handling and JetStream async reply subjects, AMQP confirm-mode lock contention, PostgreSQL/MySQL TLS configuration loading, and preserved Kafka’s default protocol version 2.1.
3. Permanently removed self-update and call-home:
   • Removed in-place binary self-update (MINIO_UPDATE) and all SUBNET registration, telemetry, license checks, and phone-home endpoints. Upgrades are managed cleanly through OS packages (RPM/DEB/APK) and container images.
4. Rebuilt a verifiable multi-architecture supply chain:
   • Built all components with Go 1.27.3 (including built-in crypto/x509 distrusted-intermediate checks), UBI 9.8 and distroless container variants, static curl 8.23.0, and Red Hat’s RHSB-2026-012 root CA blocklist.
   • Published Linux (amd64/arm64/ppc64le/s390x), macOS (amd64/arm64), and Windows (amd64/arm64 ZIP) archives, RPM/DEB/APK packages, and multi-arch Docker Hub images (pgsty/silo, pgsty/silo-console, pgsty/mc, pgsty/kes) backed by GPG signatures, SPDX SBOMs, and GitHub Sigstore build attestations (see Downloads).

8. Honest Boundaries: Withdrawn Experiments and Open Limits

Maintaining storage software in production requires knowing what to roll back when an idea does not survive real capacity or failure testing. Over the past year, we implemented, benchmarked, and deliberately withdrew or closed four designs:

1. Withdrew public persistent ListMultipartUploads disk scanning (#79):
   • Goal: Upstream’s ListMultipartUploads reads only a node-local in-memory cache, losing visibility of incomplete uploads across restarts. In September we implemented a persistent scan across storage pools and erasure sets.
   • Why we rolled it back: Capacity testing showed scan latency grew linearly with prefix depth and abandoned upload count, timing out at 20,000 incomplete uploads and amplifying drive I/O. In Server 20261018 we withdrew public persistent scanning and retired the optional strict mode, returning to the node-local cache plus exact-key lookup (see ListMultipartUploads Design and Capacity Evidence).
2. Deferred strict generation read refusal and automatic cross-pool read recovery:
   • Goal: When partial overwrite failures left split object generations across drives or pools, we tested refusing divergent reads or auto-recovering across pools during GET.
   • Why we deferred it: Fault-injection testing showed that refusing reads after a failed partial overwrite broke MinIO’s established availability contract (where the prior readable version remains accessible). Those strict diagnostics remain gated behind the non-default consistency_strict build tag while production builds preserve existing read-quorum and healing behavior.
3. Closed multi-pool overwrite affinity without merge (#245):
   • Goal: In multi-pool clusters, unversioned overwrites can land on a different pool and leave stale copies on the old pool. PR #245 routed overwrites back to the object’s existing pool.
   • Why we closed it: When the historical pool lost write quorum due to failed drives while another pool remained healthy, forced affinity caused overwrites to fail outright—and two rounds of multi-node m3 benchmarks showed small-object overwrite latency still missed our bar (see Overwrite Pool Affinity).
4. Removed experimental access-frequency intra-cluster tiering (ilm access_*):
   • The experimental feature never met production reliability requirements and was removed in Server 20260916 (see Access-Frequency Tiering Removal).

Remaining Operational and Upgrade Boundaries

When evaluating or upgrading to SILO, keep these boundaries in mind:

• No distributed lock fencing: If a node loses its lock lease during a GC pause, network partition, or stalled drive, an already-admitted commit on that node can still land late; partial metadata updates can still briefly expose stale tags or attributes. The release retains existing timeout semantics; a returned request is not proof that underlying I/O has stopped.
• No unverified cluster-wide throughput claims: We verify hot-path microbenchmarks (for example, silo-pkg v3.14.3 reduced ContainsAdminAction from 24 allocations and 742.5 ns/op to zero allocations and 5.53 ns/op), but we have not run a head-to-head multi-node benchmark between 2025-10-15 and 2026-10-26 on dedicated hardware.
• Coordinated upgrades for new IAM and replication state: While on-disk xl.meta v1.3 remains compatible, features such as durable IAM revocations (siloParentRevocation) and site-replication metadata tombstones require all participating nodes to upgrade together rather than running mixed versions indefinitely or performing rolling downgrades (see the Component Matrix and IAM Upgrade Guide).
• Known minor items: The repository’s Helm chart (7.0.3) default server image tag still points to RELEASE.2026-09-16T00-00-00Z (override image.tag in values.yaml when deploying newer releases), and two legacy batch-lifecycle handlers in Console (batch expiration and batch transition creation) have early-return/empty-slice quirks that do not affect single-rule configuration and are queued for the next Console patch.

Closing Note

When we forked MinIO a year ago, the goal was simple: keep a production-grade open-source S3 server alive with timely CVE patches, a complete administration console, honest bug fixes, and clean binary and container distributions.

One year later—604 commits, 7 CVE patches, 18 security boundary hardenings, and dozens of root-cause write-ups in our Design Archive and Security Archive—that is the ledger of what SILO has done.

If you are running open-source MinIO, see the Migration Guide and Downloads page. If you hit a reproducible protocol, replication, or storage bug in production, open an issue at pgsty/silo.

1.2 - MinIO Fork, Promise Kept

Two months ago in “MinIO is Dead, Long Live MinIO,” I promised I’d keep the MinIO fork patched. The recurring objection on HN is fair: can one person actually maintain something like this? The real answer isn’t clicking fork. It’s what happens when CVEs start landing.

Between April 15 and 17, pgsty/minio shipped RELEASE.2026-04-17, closing four CVEs and a handful of related vulnerabilities disclosed in the same window.

The scope I committed to originally was narrow: no new features, keep the supply chain running, handle reproducible bugs and security issues as they come in. This release is what it looks like when that promise gets tested.

What happened upstream

In December 2025, MinIO moved the open-source repo to maintenance mode. The README said security fixes would be “evaluated case by case.” In February 2026, the repository was archived and the landing page became “this repository is no longer maintained.”

The SECURITY.md in that same archived repo still says: “we will always provide security updates for the latest release.”

Over the past month, four high-severity and two medium-severity vulnerabilities have been disclosed against the final open-source release.

It’s been 184 days since the last upstream release. Vulnerabilities get disclosed; fixes ship only in the commercial build. The guidance for OSS users is a single line: upgrade to AIStor.

AIStor starts around $100k/year for 400 TiB — roughly S3 pricing, for software you install and operate yourself.

It’s a clean arrangement: archive the repo so there’s no obligation to patch, keep publishing CVE advisories for visibility, and route everyone who reads them toward the commercial product.

Someone still has to patch the old one.

What this release fixes

Full write-ups, CVSS arithmetic, and PoCs are in the release notes. The short version:

• CVE-2026-33322 (OIDC JWT algorithm confusion, CVSS 9.8): under certain IdP configurations, an attacker who knows the OIDC ClientSecret can mint a token claiming any identity — including consoleAdmin — and MinIO will accept it. Vulnerable window: November 2022 through March 2026. About three and a half years.
• CVE-2026-33419 (LDAP STS enumeration and brute-force): the login endpoint leaks which usernames are real, and there’s no rate limiting on the subsequent password guessing. End of the chain is an STS credential.
• CVE-2026-34204 (replication-header metadata injection): a regular PUT or COPY with certain X-Minio-Replication-* headers can write an object into a permanently unreadable state. The data is still on disk; you just can’t read it back out.
• CVE-2026-39414 (S3 Select memory exhaustion): one request, one OOM.
• GHSA-hv4r-mvr4-25vw / GHSA-9c4q-hq6p-c237: two signature-verification bypasses on the unsigned-trailer path. Anonymous or forged-signature requests can successfully write objects on certain routes.

Plus the usual dependency cleanup from go-jose, go.opentelemetry.io, and the Go 1.26.2 upgrade itself — about twenty security items in total counting transitive dependencies.

How it got fixed

I said in the earlier post that I’d rely on AI coding agents, and that’s how this round went. My role was closer to “review and decide” than “write code.”

Per-issue flow, roughly:

1. Codex drafts first. Given the CVE description and relevant code paths, it produces an initial patch.
2. Claude Code reviews adversarially. Picks holes from the attacker’s side.
3. Back to Codex. If it agrees with Claude Code’s critique, it reworks. If not, it has to write out why. No silent overrides.
4. Another round of review by Claude Code, with both sides’ reasoning on the table. Iterate until they converge.
5. Tests. Codex proposes cases, Claude Code adds more, Codex runs them, Claude Code reviews the results.
6. I decide. Read the diff, run the tests, merge or send it back with comments.

I didn’t write any of the code in this round. My job was to define the problem, set constraints, pick between approaches, read diffs, run tests, and merge. The GitHub log shows Vonng, Codex, and Claude Code as co-authors — that’s just who did the work.

A few things I noticed about how this runs in practice.

Two heterogeneous agents in opposition catch more than one agent alone. A single agent patching a security bug tends toward confident-sounding fixes that quietly miss a boundary condition. Having a second agent argue against the first filters out most of those.

It forces the tradeoffs into writing. When two implementations diverge, someone has to say why A over B. That exchange is the thing I can actually act on as the person deciding what to merge.

Real maintenance is patch-on-patch, not one-shot. The LDAP STS fix is a good example. The first version landed, and then we realized: successful requests shouldn’t count against the rate limit; X-Forwarded-For shouldn’t be trusted by default; the limiter should key on source IP plus normalized username, not just one. Three follow-up commits before it settled. Iterating through that by hand would have cost a lot more time.

Why this fork exists

Because I use MinIO myself.

MinIO is a production dependency for Pigsty. I need working binaries, a complete console, packages that keep shipping, and someone actually handling CVEs. That keeps the scope narrow. No new features, no turning the repo into a playground. Compatibility, supply chain, fixes when they’re needed.

— Chainguard also ships MinIO container images that track upstream’s post-archive commits, a useful option if you use their images. This fork is a different shape: source tree, RPM/DEB packages, restored console, and doesn’t depend on upstream continuing to push patches somewhere.

The fork is at about 1,300 stars on GitHub and 50,000+ pulls on Docker Hub now. Not remarkable numbers, but enough to tell me I’m not the only one who needed this fork to keep shipping.

2026-10-25 update: The maintained Docker image is now pgsty/silo. The Docker example below uses the current name; see the migration guide.

If you’re already running OSS MinIO, migration is cheap:

• Docker: swap minio/minio for pgsty/silo.
• RPM / DEB: on GitHub Releases, or via pig.
• Source: pgsty/minio
• Docs: silo.pgsty.com

You don’t need to replace anything around it or relearn the API. In most cases, you’re just pointing a compatible binary at the same deployment. If you want a full HA production setup, Pigsty ships one for free.

Something I use broke; I’m fixing it.

What’s different in 2026 is the cost of “I’m fixing it.” With two coding agents and someone to referee between them, the maintenance load of a mid-sized Go codebase is tractable for one person in a way it wasn’t a year or two ago. That’s about it — not a grand theory about open-source resilience, just the current operating point.

If you’re running OSS MinIO, the migration is cheap and the patches are current. If another CVE drops, I’ll still be here.

• MinIO Is Dead, Long Live MinIO
• From AGPL to Apache: Reflections on Pigsty’s License Change
• Originally published in Chinese

1.3 - MinIO Is Dead, Long Live MinIO

MinIO’s open-source repo has been officially archived. No more maintenance. End of an era — but open source doesn’t die that easily.

I created a MinIO fork, restored the admin console, rebuilt the binary distribution pipeline, and brought it back to life.

2026-10-25 update: The maintained Docker image is now pgsty/silo. The Docker links and examples below use the current name; see the migration guide.

If you’re running MinIO, swap minio/minio for pgsty/silo. Everything else stays the same. (CVE fixed, and the console GUI is back)

The Death Certificate

On December 3, 2025, MinIO announced “maintenance mode” on GitHub. I wrote about it in MinIO Is Dead.

On February 12, 2026, MinIO updated the repo status from “maintenance mode” to “no longer maintained”, then officially archived the repository. Read-only. No PRs, no issues, no contributions accepted. A project with 60k stars and over a billion Docker pulls became a digital tombstone.

If December was the clinical death, this February commit was the death certificate.

Today (Feb 14), a widely circulated article titled How MinIO went from open source darling to cautionary tale laid out the full timeline.

Percona founder Peter Zaitsev also raised concerns about open-source infrastructure sustainability on LinkedIn. The consensus in the international community is clear:

MinIO is done.

Looking back at the timeline over the past years, this wasn’t a sudden death. It was a slow, deliberate wind-down:

A company that raised $126M at a billion-dollar valuation spent five years methodically dismantling the open-source ecosystem it built.

But Open Source Endures

Normally this is where the story ends — a collective sigh, and everyone moves on.

But I want to tell a different story. Not an obituary — a resurrection.

MinIO Inc. can archive a repo, but they can’t archive the rights that the AGPL grants to the community.

Ironically, AGPL was MinIO’s own choice. They switched from Apache 2.0 to AGPL to use it as leverage in their disputes with Nutanix and Weka — keeping the “open source” label while adding enforcement teeth. But open-source licenses cut both ways — the same license now guarantees the community’s right to fork.

Once code is released under AGPL, the license is irrevocable. You can set a repo to read-only, but you can’t claw back a granted license. That’s the beauty of open-source licensing by design: a company can abandon a project, but it can’t take the code with it.

So — MinIO is dead, but MinIO can live again.

That said, forking is the easy part. Anyone can click the Fork button. The real question isn’t “can we fork it” but “can someone actually maintain it as a production component?”

Why would I do that?

I didn’t set out to take this on. But after MinIO entered maintenance mode, I waited a couple of weeks for someone in the community to step up.

But I didn’t find one. So I did it myself.

Some background: I maintain Pigsty — a batteries-included PostgreSQL distribution with 460+ extensions, cross-built for 14 Linux distros. I also maintain build pipelines for 290 PG extensions, several PG forks, and dozens of Go Projects (Victoria, Prometheus, etc.) packaging across all major platforms. Adding one more to the pipeline was a piece of cake.

I’m not new to MinIO either. Back in 2018, we ran an internal MinIO fork at TanTan (back when it was still Apache 2.0), managing ~25 PB of data — one of the earliest and largest MinIO deployments in China at the time.

More importantly, MinIO is an optional module in Pigsty. Many users run it as the default backup repository for PostgreSQL in production. We did consider several alternatives, but none were a drop-in replacement for MinIO-based workflows.

We use MinIO ourselves, so keeping the supply chain alive was not optional — it had to be done. As early as December 2025, when MinIO announced maintenance mode, I had already built CVE-patched binaries and switched to them.

pgsty/minio RELEASE.2025-12-03T12-00-00Z

What We’ve Done

As of today, three things.

1. Restored the Admin Console

This was the change that frustrated the community the most.

In May 2025, MinIO stripped the full admin console from the community edition, leaving behind a bare-bones object browser. User management, bucket policies, access control, lifecycle management — all gone overnight. Want them back? Pay for the enterprise edition. (~$100,000)

We brought it back.

The ironic part: this didn’t even require reverse engineering. You just revert the minio/console submodule to the previous version. They swapped a dependency version to replace the full console with a stripped-down one. The code was always there.

We put it back.

2. Rebuilt Binary Distribution

In October 2025, MinIO stopped distributing pre-built binaries and Docker images, leaving only source code. “Use go install to build it yourself” — that was their answer.

For the vast majority of users, the value of open-source software isn’t just a copy of the source — supply chain stability is what matters. You need a stable artifact you can put in a Dockerfile, an Ansible playbook, or a CI/CD pipeline — not a requirement to install a Go compiler before every deployment.

We rebuilt the distribution:

Docker Images

pgsty/silo is live on Docker Hub. docker pull pgsty/silo and you’re good.

RPM / DEB Packages

Built for major Linux distributions, matching the original package specs.

CI/CD Pipeline

Fully automated build workflows on GitHub, ensuring ongoing supply chain stability.

If you’re using Docker, just swap minio/minio for pgsty/silo.

For native Linux installs, grab RPM/DEB packages from the GitHub Release page. You can also use pig (the PG extension package manager) for easy installation, or configure the pigsty-infra APT/DNF repo to install from it:

curl https://repo.pigsty.io/pig | bash; 
pig repo add infra -u; pig install minio

Just works as usual.

3. Restored Community Edition Docs

MinIO’s official documentation was also at risk — links had started redirecting to their commercial product, AIStor.

We forked minio/docs, fixed broken links, restored removed console documentation, and deployed it as the SILO documentation site.

The docs use the same CC Attribution 4.0 license as the original, with necessary maintenance.

Commitments

Some things worth stating up front to set expectations.

No New Features — Just Supply Chain Continuity

MinIO as an S3-compatible object store is already feature-complete. It’s a finished software. It doesn’t need more bells and whistles — it needs a stable, reliable, continuously available build. (I already have PostgreSQL for these, so I don’t need something like S3 table or S3 vector. A stable S3 core is all I need)

What we’re doing: making sure you can get a working, complete MinIO binary, with the admin console included and CVE fixed. RPM, DEB, Docker images — built automatically via CI/CD, drop-in compatible with your existing minio. We keep the existing minio naming and behavior where legally and technically feasible.

This Is a Production Build, Not an Archive

We run these builds ourselves and have been dogfooding them in production for three months. If something breaks, we detect it early and patch it quickly.

I build this primarily for Pigsty and our own usage, but I hope it helps others too.

I’m willing to Track CVEs and Fix Bugs

If you run into issues, feel free to report them at pgsty/minio. I’ll do my best to fix these — but please don’t treat this as a commercial SLA.

Given that AI coding tools have made bug fixing dramatically cheaper, and that we’re explicitly not adding any new features, I believe the maintenance workload is manageable. (how often do you see one?)

Trademark Is Tricky, But We’ll Cross That Bridge When We Come to It

Disclaimer

Trademark Notice: MinIO® is a registered trademark of MinIO, Inc. This project (pgsty/minio) is an independently maintained community fork under the AGPL license. It has no affiliation with, endorsement by, or connection to MinIO, Inc. Use of “MinIO” in this post refers solely to the open-source software project itself and implies no commercial association.

AGPLv3 gives us clear rights to fork and distribute, but trademark law is a separate domain. We’ve marked this clearly everywhere as an independent community-maintained build.

If MinIO Inc. raises trademark concerns, we’ll cooperate and rename (probably something like silo or stow). Until then, we think descriptive use of the original name in an AGPL fork is reasonable — and renaming all the minio references doesn’t serve users.

AI Changed the Game

You might ask: can one person really maintain this?

It’s 2026. Things are different now.

AI coding tools are changing the economics of open-source maintenance.

With tools like Claude Code & Codex, the cost of locating and fixing bugs in a complex Go project has dropped by more than an order of magnitude. What used to require a dedicated team to maintain a complex infra project can now be handled by one experienced engineer with an AI copilot.

Maintaining a MinIO build without adding new features is a manageable task. The key requirement is testing and validation. and we already have that scenario, which lets us verify compatibility, reliability, and security in practice.

Consider: Elon cut X/Twitter’s engineering team down to ~30 people and the system still runs. Maintaining a MinIO fork without new features is considerably less daunting

Just Fork It

MinIO Inc. can archive a GitHub repo, but they can’t archive the demand behind 60k stars, or the dependency graph behind a billion Docker pulls. That demand doesn’t disappear — it just finds its way out.

HashiCorp’s Terraform got forked into OpenTofu, and it’s doing fine. MinIO’s situation is actually more favorable — AGPL is more permissive for forks than BSL, with no legal gray area for community forks. A company can abandon a project, but open-source licenses are specifically designed so the code can’t die.

Fork is the most powerful spell in open source. When a company decides to shut the door, the community only needs two words:

Fork it.

Reference

• MinIO Is Dead
• MinIO Is Dead, Are There Alternatives?
• From AGPL to Apache: Reflections on Pigsty’s License Change
• MinIO: Promise made, Promise kept

Originally published in Chinese

1.4 - MinIO Is Dead. Which Next?

MinIO announced maintenance mode two days ago. I ranted in “MinIO Is Dead” and immediately got flooded with “so what now?”

The usual suspects: Ceph, RustFS, SeaweedFS, Garage. I packaged all of them for Linux (RPM/DEB) and ran them through the grinder.

Short version: there’s no perfect substitute. Ceph is powerful but overkill; SeaweedFS rocks tiny files but needs an external metadata DB; Garage is cute but too barebones; RustFS targets the MinIO niche but is still alpha.

Quick scan of the field

MinIO is the open-source S3 clone. If all you need is basic object CRUD, any S3-compatible store works. But parity with MinIO means more than APIs—it’s about reliability, operability, tooling, documentation, SOPs. Replacing it cleanly is hard.

Ignoring commercial clouds, here’s the OSS menu:

• Ceph – arguably the best choice for enterprises, but brutally complex. Most folks don’t need block + file + object in one, and it requires extras like Podmon. MinIO’s single binary spoiled us.
• SeaweedFS – optimized for oceans of small files; O(1) disk seeks make it absurdly fast there. But it relies on an external metadata store. If you want a general-purpose object store, that dependency is annoying.
• Garage – built by Deuxfleurs with NGI funding. Delightfully light (10 MB), great for self-hosters and edge nodes. But S3 compatibility is thin: no versioning, no cross-region replication, no IAM. Enterprises will laugh.
• RustFS – the only project explicitly chasing “drop-in MinIO,” but it’s still alpha.

RustFS vs. MinIO

RustFS looked the most promising, so I wired it into Pigsty as a MinIO replacement. Most logic carried over, but a few differences popped up:

• Certificates must follow specific naming rules.
• Health checks differ from MinIO’s endpoints.
• mc admin doesn’t work; you can’t push fine-grained IAM policies. That’s a deal-breaker for many teams.

It ran, but I’m not shipping alpha software into production, so I shelved the branch. I’ll revisit when RustFS hits GA.

Will RustFS repeat MinIO’s mistakes?

RustFS has potential, but I worry it’ll retrace MinIO’s path. I asked the AI big three (GPT‑5 Pro, Claude 4 Opus, Gemini 3 Pro) to audit the project. Gemini leveled some serious accusations; Claude corroborated.

The red flags match MinIO’s history: Apache 2.0 license + copyright assignment CLA + single commercial gatekeeper. With that risk profile, I’m downgrading RustFS from “optimistic” to “cautious wait-and-see.”

So what now?

Pigsty bundles MinIO as an optional module for PostgreSQL backups or as an on-prem S3 for apps like Supabase. After surveying the alternatives, I’m not eager to swap it out. I might add a pgBackRest-native backup server option, but ripping out MinIO today feels premature.

Best plan: stay on the latest MinIO release, lock the version, isolate it on the network, and wait a few months. Maybe the community forks it; maybe RustFS matures. Adjust when reality changes.

RustFS still has a golden window to seize MinIO’s niche with a safer, community-friendly fork. That window is measured in months, not years.

If you stick with MinIO

Use the latest build, not the April 22, 2025 edition with the GUI. There’s a serious CVE in the interim:

• CVE-2025-62506 – privilege escalation via session-policy bypass (HIGH). Low-privilege users can mint new accounts and escalate.

In a locked-down intranet the risk is manageable, but you still want the fix, which landed in the 2025‑10‑15 release. MinIO pulled the prebuilt binaries starting with that version, offering source only. Annoying, but it’s Go—go build and you’re done. I forked MinIO, ran their packager, and produced RPM/DEBs for 2025‑12‑03 so I’m not deploying vulnerable bits: https://github.com/pgsty/minio

Security patches still need humans. MinIO claims they’ll fix critical issues, but if the community wants a maintained fork, now’s the moment. Start from 2025‑04‑22, cherry-pick critical bug/security fixes, and keep a community LTS alive.

MinIO is “done” software. It doesn’t need the latest S3 gimmick (Vector/Table); it needs steady bugfixes. That’s perfect for a community branch. Plenty of storage vendors rely on MinIO; maintaining a fork beats writing a new object store from scratch.

2026-02-14 Update: MinIO’s official repo has been fully archived and is no longer maintained. Besides, I’ve personally maintained an oss fork of minio: pgsty/minio / Docs: https://silo.pgsty.com. Which based on the last upstream version 2025-12-03 with restored console capabilities.

1.5 - MinIO is Dead

December 3, 2025 was a day to mark in open-source software history. MinIO’s team updated the project status on GitHub, announcing the MinIO open-source project was entering “maintenance mode.” This basically declared the death of MinIO as an open-source project.

MinIO the company has finally completed its transformation from a dragon-slaying hero into the very dragon it once sought to slay.

From Dragon-Slayer to Dragon

Democratization Era (2014–2019): The Apache of Object Storage

MinIO was founded in 2014 with a highly idealistic vision – to be “the Apache of object storage.” In an era dominated by AWS S3, MinIO’s ultra-lightweight design (a single static binary) and 100% S3 API compatibility quickly won developers’ hearts.

During this phase, MinIO was licensed under the liberal Apache 2.0 license, encouraging developers to integrate it into all kinds of applications. Its core pitch: “turn any hardware into AWS S3.” This open strategy was wildly successful. MinIO claimed its Docker image had been pulled over 1 billion times, making it the world’s most widely deployed object storage service. At this point, MinIO was a darling of the cloud-native stack – the default storage backend in many Kubernetes setups.

License Weaponization (2019–2025): The AGPL War

The first major crack in community relations appeared around 2019–2021. MinIO announced it was changing its core license from Apache 2.0 to GNU AGPLv3.

The official explanation was that this move aimed to prevent cloud providers (like AWS, Azure) from “freeloading” the code and repackaging it as proprietary services — a common defensive tactic in open source. During this period, MinIO shifted from being a community guardian to an aggressive defender of its IP. In 2022, MinIO publicly accused Nutanix Objects of violating its license and revoked Nutanix’s right to use MinIO; in 2023, MinIO sued high-performance filesystem vendor Weka on similar grounds. These legal actions, though legally contentious, sent a clear signal: MinIO no longer welcomed commercial use without paying up. This set the legal and psychological stage for the full lockdown that would come in 2025.

Control Plane Neutered (May 2025)

In May 2025, MinIO decided to strip the MinIO Console out of the community edition. The console was a critical GUI for bucket management, IAM, monitoring, and audit logging. After this removal, the open-source MinIO was left with only a basic “object browser” GUI – essentially just a file viewer/downloader.

Meanwhile, key admin features like policy management, site replication configuration, and lifecycle management were moved entirely into the commercial enterprise edition. This change downgraded the open-source MinIO from a full-featured storage management system into a mere data-plane component, robbing it of the control-plane capabilities needed to run as a standalone product in production.

Cutting Off Binary Distribution (Oct 2025)

On October 15, 2025 – right as a critical security vulnerability (CVE-2025-10-15T17-29-55Z / GHSA-jjjj-jwhf-8rgr) was disclosed – MinIO stopped publishing updated Docker images to Docker Hub and Quay.io. The timing of this move was highly strategic. By cutting off binaries during a major security incident, MinIO effectively used security as a bargaining chip.

This decision directly broke the automated deployment pipelines for countless users. Helm charts, Ansible playbooks, and Terraform scripts expecting minio/minio (or Bitnami’s minio) image suddenly failed to find updates. Auto-scaling groups trying to pull new nodes hung due to missing images. For teams without a Go build environment or an internal container registry, MinIO instantly became unusable.

Maintenance Mode (Dec 2025)

On December 3, 2025, MinIO, Inc. officially updated its channels and GitHub repo to announce that the open-source project is now in “maintenance mode.” The README stated that there will be no further feature additions or improvements, issues and PRs will no longer be reviewed, and even critical security fixes would be provided “as appropriate.” No more RPM/DEB packages or Docker images will be released. Essentially, anyone needing updates or support is advised to switch to the commercial AIStor product.

Technical Impact: Damage to the Open-Source Ecosystem

MinIO’s move to maintenance mode dealt an immediate and far-reaching blow to many tech stacks.

Broken CI/CD Pipelines and an Automation Crisis

Thousands of Helm charts, Ansible playbooks, and Terraform scripts depend on the minio/minio (or Bitnami’s minio) container image. With official images no longer published, third-party packagers like Bitnami — who can’t get a stable upstream release — also had to stop updates.

• Cascade effect: Deployments in fresh environments started failing outright. Auto-scaling groups, upon launching new instances, would hang or error out when the MinIO image couldn’t be pulled.
• Cost of fixes: Companies now have to rewrite their deployment scripts to point to a self-hosted image, and set up internal build pipelines to compile and package MinIO from source.

Security Vacuum: CVE Patches Go Private

The most lethal consequence of halting binary distribution is delayed security patches. In the October 2025 incident, for example, MinIO effectively withheld the patched binaries for the vulnerability.

• Risk exposure: Companies without dedicated security teams are forced to keep running older, vulnerable versions with known critical flaws.
• Compliance nightmare: For organizations under PCI-DSS, HIPAA, SOC2, etc., not being able to obtain vendor-signed security updates is a compliance disaster. Lacking official patches, they technically fall out of compliance.

Exponentially Higher Ops Complexity

Removing the UI wasn’t just a hit to user experience – it increased operational burden. Tasks that used to be a few clicks in the Console (configuring bucket policies, setting user permissions) now require ops engineers to master the mc CLI or hand-craft complex JSON policy docs. This raises the skill floor and makes MinIO far less friendly as a lightweight internal tool.

Underlying Reasons: Pressure from Capital and Commercialization

The driving force behind MinIO’s decisions is the logic of venture capital. By 2025, MinIO had raised a total of $126 million in funding. The most significant was a $103 million Series B in January 2022 led by Intel Capital, SoftBank Vision Fund II, and General Catalyst, which crowned MinIO a unicorn (valued over $1 billion).

In VC terms, a $1B valuation means the company must show a clear path to IPO — typically demanding $100M+ in Annual Recurring Revenue (ARR) and rapid growth. In Feb 2025, MinIO announced its ARR had grown 149% over the past two years businesswire.com. Impressive growth, but to live up to a sky-high valuation, organic conversion alone wasn’t enough.

Cutting off the free open-source offering is the most direct way to force a huge user base into paid customers.

In 2025, MinIO underwent a full rebrand and launched “MinIO AIStor,” styling itself as “the data backbone for enterprise AI.” Management recognized that general-purpose object storage (for backups, file servers, etc.) was a red-ocean market with thin margins, whereas generative AI’s appetite for high-throughput data (the exascale AI era) promised the next big surge. By tuning its product for AI workloads and focusing on Fortune 500 enterprises linkedin.com, MinIO essentially decided to cut loose its low-value open-source user base. The move to maintenance mode signaled MinIO’s official pivot from a broad open-source project into a vertical, high-end AI software vendor.

MinIO isn’t a garage hobby project by a few geeks anymore; it’s a company that took $126M in VC and is valued at over $1B. Backed by Intel Capital and SoftBank, once you take that money, your boss is no longer the users — it’s the investors. And what do investors want? ARR, growth, IPO. You tell them, “We have a billion Docker pulls!” and they’ll ask, “How many dimes did those pulls pay us?”

The reality is brutal. To the VCs, those small businesses and individual devs using free MinIO are low-value assets. They open issues and ask for support — consuming expensive engineer time, bandwidth, and servers — yet will never convert to paying customers. MinIO’s leadership knows their real cash cows are the Fortune 500 firms doing generative AI. The ones training GPT models or running self-driving pipelines need AIStor, ultra-high performance, and 24/7 enterprise SLAs.

So flipping the project into “maintenance mode” is essentially an asset carve-out. MinIO is cutting away the “dead weight” (free users) and concentrating on the milkable “cash cows” (enterprise AI clients). In business strategy this is called focus. To the investors, it’s being responsible. But from the perspective of open source, it’s simply betrayal.

Personal Reflections

I started using MinIO around 2018 (back when it was Apache-licensed). We built a few multi-petabyte object storage clusters for videos, images, backups — probably one of the largest MinIO deployments in China at the time. I wrote deployment/monitoring playbooks for MinIO (still open-sourced in Pigsty).

As an open-source startup founder, I can understand the motivation behind these moves. But as an open-source contributor and user — I also know many folks right now have one phrase in their minds: “I have never seen such shamelessness.”

An open-source license isn’t a shackle, but it is a social contract. Developers contribute code, users contribute testing, feedback, and reputation; together, they make a project successful. MinIO enjoyed a decade of community goodwill and parlayed the bragging rights of “#1 in global downloads” into venture funding. Then it turned around and told the very users who propped it up: “You free-riders, get lost.” This kind of move breaks the fundamental trust that open source is built on.

This “bait and switch” tactic is even more nauseating than a crypto rug pull. A rug pull only takes your money — MinIO is pulling the rug out from under the tech stacks of thousands of companies. Adopting a technology isn’t just picking up a binary; it’s buying into an ecosystem and a design philosophy. They got everyone onboard, let the switching costs pile up sky-high, and then suddenly kicked away the ladder. In fact, as open-source expert Tison thoroughly discussed in his article The Bait-and-Switch Open-Source Strategy, the core issue with this model is deception.

MinIO betrayed the community, so the community may abandon it as well. Alternatives like Garage, SeaweedFS, or the new RustFS are ready to step in.

If I have to sum up my feelings, I’d borrow a line from The Hitchhiker’s Guide to the Galaxy:

—— “So long, and thanks for all the fish.”

2026-02-14 Update: MinIO’s official repo has been fully archived and is no longer maintained. Besides, I’ve personally maintained an oss fork of minio: pgsty/minio / Docs: https://silo.pgsty.com. Which based on the last upstream version 2025-12-03 with restored console capabilities.

2 - Release Notes

Release notes track feature updates, security fixes, dependency upgrades, compatibility requirements, and artifact delivery across the SILO stack.

The 20261026 coordinated release consolidates all SILO Server, mcli, and KES changes since 20261018 alongside Console 2.5.1 and silo-pkg 3.15.2 (the October 24–25 maintenance drafts have been folded into the final release notes, with their URLs redirecting automatically).

2.1 - SILO 20261026: Server, mcli and KES

SILO, mcli, and PGSTY KES 20261026 are now released, alongside SILO Console 2.5.1 and silo-pkg 3.15.2. This article consolidates the October 24–25 maintenance records and summarizes all changes since the 20261018 release. All three executables share the same release date and package version; KES remains an optional, independently deployed key encryption service.

Released components

All five projects build with Go 1.27.3. Server, Console, and mcli select silo-pkg v3.15.2 and the pinned upstream commit minio-go v7.4.2-0.20261025165926-320af050c445 (a pseudo-version rather than an upstream v7.4.2 tag). Server explicitly embeds the released Console and mcli sources; upgrading standalone Console does not replace the UI embedded inside an older Server binary. See the component matrix and downloads.

Server changes since 20261018

• LDAP and IAM (#250): Restores group-based login for LDAP users whose normalized DNs exceed 255 bytes in a single ASCII path component by treating missing optional IAM records on those paths as absent, while continuing to fail closed on unreadable revocation records or storage errors (writing overlong path records remains unsupported on the object backend). Policy reloads no longer hold the authentication-cache lock during storage I/O, swap the cache only after a complete load, and preserve IAM write ordering. Request cancellation now propagates to KMS and SSE-S3 decryption paths without shortening the caller’s policy-query deadline.
• Built-in policy Reset and live bucket inventory: Resetting an overridden built-in policy immediately restores the native policy definition on the next read, while delayed peer/etcd notifications reload committed state without clobbering newer edits (in-use checks, delete revisions, and custom-policy deletion remain unchanged). Console’s account-info endpoint now reads the live bucket inventory so newly created or deleted buckets appear immediately on refresh, while object usage totals remain scanner-derived.
• Multi-pool deletion safety (#257, #256): Ordinary and bulk deletes clean non-authoritative duplicate pools before removing the authoritative copy, select an available pool when writing new delete markers, and protect remote-tier payloads still referenced by surviving copies.
• Versioned lifecycle expiration (#253, #252): Retains remote tier payloads whenever lifecycle expiration only inserts a delete marker (including non-null versions in versioning-suspended buckets), reclaiming remote tier objects only when a historical version is permanently purged and no surviving reference needs its payload.
• Multipart replication (#255, #254): Forwards the FULL_OBJECT checksum type when replicating CRC multipart objects so the target cluster does not reject the replica with BadDigest.
• Storage RPC and timeout semantics: Forwards storage RPC deletion options (including the previous data directory needed for overwrite rollback) while preserving existing drive/RPC deadlines, request cancellation, object locking, read quorum, and healing rules. The final release withdrew the 20261025 draft’s admitted-I/O draining waits and per-object mutation guards (including #258) in dcc2f20ba; see the multi-pool object consistency record.
• Dependencies, packaging, and delivery: Updates SFTP, etcd, NATS, cloud SDKs, and other Go modules; preserves Kafka’s default protocol 2.1, CLI formatting, and NetBSD compatibility; and fixes legacy DARE v1 unsealing while keeping v2 writes. Container images, the verified installer, and Helm client jobs bundle mcli 20261026. Windows archives now ship as .zip, static curl is updated to 8.23.0 with the certificate-trust mitigation described below, and RPM signer verification is fixed during the final SBOM/provenance refresh.
• Documentation and migration: Incorporates the single-node MinIO migration guide (#228), reconciles operational defaults, and consolidates upgrade instructions under the migration guide.

This release retains all Object Lock, IAM authorization, durable STS revocation, pool-migration, and LIST recovery repairs shipped in 20261018. The dependency security inventory below separates newly adopted fixes from earlier repairs and scanner findings in unused code paths.

mcli changes since 20261018

• Client identity cache isolation (#50, #55): Isolates cached S3 and admin clients by credentials, TLS trust, proxy, custom resolver, and request headers while preserving credential refresh and token-file rotation.
• Replication resync status and throughput (#48, #49, #52): admin replicate resync status --json drains the status stream through terminal Completed, Failed, or Canceled states so completed jobs emit their final JSON record; explicitly reports when replication is disabled; stops waiting on Failed or Canceled in TTY mode; and fixes integer overflow in throughput calculations past ~8.6 GiB.
• Honest exit codes (#51): resync start and resync cancel retain per-bucket error details and return a nonzero exit code when any bucket fails, while resync status continues to exit 0 when successfully inspecting an already Failed or Canceled job. admin info --json also exits nonzero on request failure while preserving its JSON error output.
• Batch job observation (#53, #54): batch status continues watching when live metrics are not yet available, emits a pending status instead of treating queued or missing samples as complete, falls back to bounded persisted-status queries when the metric stream ends early, and fixes IOPs integer overflow on large object counts.
• Alias regions (#44): Honors persisted alias region settings with precedence MC_REGION → AWS_REGION → alias configuration → bucket-location discovery, and isolates signing regions across cached clients (without adding an alias set --region CLI flag).
• SDK fixes: Rejects truncated sequential or parallel multipart streams; preserves ReadAt EOF/negative-offset semantics and post-Stat read/seek bounds; deduplicates fallback batch-delete errors; and accepts both HTTP 200 and 204 when removing bucket replication configurations (while still reporting 403 and other real errors).
• Packaging and help (#45): Builds with Go 1.27.3 and GoReleaser 2.19.0, switches Windows archives to .zip, refreshes help URLs and disabled server-update/SUBNET messages, and preserves existing CLI configuration and MC_* environment variables.

Automation scripts should handle the pending batch state and nonzero exit codes on partially failed resync start/cancel commands. Upgrading mcli requires no Server protocol change. Mid-stream download interruptions still fail immediately; SIGINT during a multipart upload exits 130, and incomplete upload parts may require explicit cleanup. See the complete client commit history.

KES changes since 20261018

KES 20261026 rolls up the Go 1.27.3 toolchain and cloud-SDK dependency maintenance and aligns the executable, Linux packages, and container images with the 20261026 release batch. Its HTTP API, configuration schema, and stored-key format remain unchanged.

The 25 module updates also cover AWS support packages and Google generated APIs, while keeping Lip Gloss v1 and gopkg.in/yaml.v3. Packaging uses GoReleaser 2.19.0 and nFPM 2.48.0; Linux packages install /usr/local/bin/kes without auto-starting an unconfigured service.

Compatibility checks verified OpenBao KV v2 and local Moto Secrets Manager fixtures across pre-upgrade and post-upgrade encrypted objects, version rollbacks, and cold Server restarts. Preserve persistent keys, certificates, and configuration across upgrades, and verify object decryption after restarting Server. See the complete KES commit history.

Console 2.5 and silo-pkg 3.15

Console 2.5.1 delivers the 2.5 interface refresh, permission-aware navigation, Overview dashboard, bounded object previews, Tasks center, identity management, and high-latency diagnostic stream fixes; the 2.5.1 patch additionally preserves group members during status changes, OIDC string-array group permissions, secure session cookies behind TLS proxies, exact UTF-8 credential exports, streaming ZIP error statuses, and keyboard focus/accessibility labels. Server 20261026 embeds Console 2.5.1 directly.

silo-pkg 3.15.2 combines the 3.15.0 Go 1.27.3 and dependency refresh, 3.15.1 upstream SDK fixes, and 3.15.2 HTTP 204 handling when removing bucket replication, while retaining existing policy semantics and the 3.14.3 admin-action lookup optimization. As a Go source module, silo-pkg is adopted by rebuilding dependent applications.

Upgrade and failure boundaries

1. Coordinated upgrade: Back up IAM state, configuration, and encryption keys, and upgrade all Server nodes and replication peers together following the IAM upgrade guide. Running mixed old/new Server versions against a shared IAM backend or performing rolling downgrades remains unsupported.
2. Post-upgrade checks: Verify LDAP/OIDC login, built-in policy Reset, bucket list refresh, versioned reads, cross-site replication, and encrypted-object decryption. The FULL_OBJECT multipart replication fix requires upgrading the sending Server first and then checking its pending replication queue.
3. Archive formats and scripts: Windows archives now use .zip (Linux and macOS retain .tar.gz); update automation scripts for mcli batch status pending outputs and nonzero exit codes on partially failed resync start/cancel commands. Existing environment variables, configuration filenames, and on-disk formats remain unchanged.
4. Known multipart and issue scope: Public ListMultipartUploads continues to use the node-local in-memory cache and exact-key lookup, ignoring the retired strict switch with a startup warning. Issues #79 and #217 remain open, webhook hot-reload PR #249 is not included, and broader performance symptoms remain tracked in #251.

Storage timeout and consistency boundary: A client-visible request timeout does not guarantee that underlying disk or RPC I/O has stopped or that the write failed to commit. Late commits, delayed rollbacks, and stale values or tags remain possible after partial drive failures, lock lease expiration, or network partitions. This release does not add distributed lock fencing and cannot automatically recover previously lost objects, remote tier payloads, or metadata.

Downloads and verification

See the download matrix for platform archive filenames, SHA-256 checksums, Linux packages, and verification commands. Versioned container images are available on Docker Hub:

docker pull docker.io/pgsty/silo:RELEASE.2026-10-26T00-00-00Z
docker pull docker.io/pgsty/mc:RELEASE.2026-10-26T00-00-00Z
docker pull docker.io/pgsty/kes:RELEASE.2026-10-26T00-00-00Z
docker pull docker.io/pgsty/silo-console:v2.5.1

• Server standard image (Linux amd64/arm64 manifest): sha256:7bb2aff6b89efe1cb1303c10fc21d579447434ed06649ac9ec05a5e2dbf30ad7 (matches latest)
• Server distroless image (Linux amd64/arm64 manifest): sha256:e6544a902f426f2b4e775b89f3c1cd78310dbffc262d1ed82e9800c1cb1b5885 (matches distroless, with native silo healthcheck ready configured on both architectures; see the Server image workflow)

Each component’s artifacts are identified by its release commit, archive checksums, package signatures, and build provenance:

• Server artifact verification: Verified 36 release assets and 34 attested subjects (including six platform binaries and six Linux packages) built from c3ad836aed0d. Both RPM packages are GPG-signed, and the checksum manifests, SBOMs, and provenance attestations match the final packages (see the Go CI, VulnCheck, Release, and Finalize workflows).
• Local multi-node and fault-injection verification: Passed 88 baseline four-node, 88 upgraded four-node, and 136 eight-node multi-pool S3 checks on Linux arm64, preserving historical objects, tags, encrypted objects, and in-flight multipart uploads across the coordinated upgrade. Rolling restarts, SIGKILL, and a 75-second pause/recovery test passed with all 408 acknowledged writes read back with matching hashes and complete listings; the native trusted-TLS mcli suite and 16 persistence checks also passed. Because health endpoints evaluate reported drive quorum rather than per-node installed peer connections, run a data-path check before resuming traffic after a restart (see Startup Readiness Window).
• KES artifact and integration verification: Verified all 19 public assets, 11 attested subjects, and both signed RPMs. OpenBao KV v2 and Moto fixtures exercised the Darwin arm64 KES binary across upgrade, rollback, and cold Server restarts—first against SILO 20261018 and then against the final Server/mcli 20261026 Linux arm64 binaries. Both KES Linux container images match the archive binaries, with multi-architecture manifest digest sha256:ea36fcdd260c606eb89e693b0949aea73b149359605273a98fcf13c8433049cd (Release workflow · Image workflow).

Contributors and change history

Thanks to Denis Babchuk / @botdeniska for lifecycle, replication, and multi-pool deletion repairs; @910patin for long-DN LDAP login; Azat / @azataiot for reproducing high-latency health-report truncation; @MikeVL for reporting resync throughput overflow and JSON status output gaps; @mrjavadseydi for alias-region support and the webhook reload proposal; Gerald Combs / @geraldcombs for Windows archive feedback; @yupoet for the single-node migration guide; and @GhaziTriki, @devTeam-AiReg, and @sargarass for their bug reports and feedback.

The table below summarizes the community Issues and PRs merged, adopted, or tracked across the five component repositories during this release cycle:

The community contributor roll recognizes every human issue and PR author across all repositories. Full commit comparisons: Server, mcli, KES, Console, and pkg.

The sections below summarize the October 22–25 dependency and security audit records (dependencies shared across multiple components are listed once under the corresponding package):

Additional Go dependency updates on October 24

The Go toolchain remains 1.27.3. Compared with the October 22 candidate dependencies, this update includes 26 newly released third-party module versions, plus Arrow and codescan updates (28 modules in total):

Public API behavior and output formats remain unchanged; see the component table above for the final pinned module versions.

Included runtime security fixes

Go and certificate trust

CVE-2026-111943 / GO-2026-6809: Go 1.27.3 rejects known untrustworthy intermediate certificates in crypto/x509, protecting TLS verification even when host trust stores have not yet been updated. All five primary projects and the standalone debugging modules are built with Go 1.27.3.

In addition, the UBI container trust stores for SILO, mcli, and KES apply the root certificate blocklist from Red Hat RHSB-2026-012. Because blocking a root rejects every certificate chain anchored under that root, this container-level mitigation is broader than Go 1.27.3’s intermediate-certificate check; external services still using certificates chained to those roots must rotate their certificate chains. See Locally mitigated items below for the UBI CA package status.

SFTP dependency hardening

pkg/sftp 1.13.12 fixes three security issues disclosed on October 23. At the time of this review, none has a CVE identifier. They are recorded separately by GHSA and are not counted as new CVEs:

Because the latter two upstream advisories have inconsistent affected-range and patched-version metadata, this batch upgrades directly to 1.13.12 containing the code fixes and verifies them with regression tests (the Go vulnerability database snapshot remains at October 21 and has not yet ingested these October 23 advisories).

Static curl and linked libraries

The static curl binary bundled in SILO container images is upgraded from 8.22.0 to 8.23.0 (built with HTTP/2, SSH, and Brotli enabled over the OpenSSL backend). The table below lists all 21 CVEs from the official curl 8.22.0 vulnerability summary alongside their applicability to SILO’s static build:

The statically linked Alpine libraries are also updated to the following patched revisions (-rN denotes the Alpine security backport revision):

The previous SILO arm64 image already linked OpenSSL 3.5.9-r0, nghttp2 1.70.0-r0 (CVE-2026-58055), and zlib 1.3.2-r1 (CVE-2026-85091); this update enforces minimum version floors in the build script and verifies both architectures against the official Alpine security metadata.

Build and development security fixes

This section covers the Node.js, Vite, and code-generation toolchain used during SILO Console frontend compilation and testing (Console runs in production as a compiled Go server binary), as well as the standalone Go debugging modules in the server repository.

Node 24.22.1

The build environment updates Node.js from 24.22.0 to 24.22.1, addressing all eight Node 24.x CVEs in the October 2026 Node.js security release (excluding Node-26-only findings):

Node 24.22.1 updates bundled Undici from 7.29.1 to 7.30.1, resolving eight CVEs documented in the Undici v7.30.1 release notes:

Node 24.22.1 also updates bundled OpenSSL from 3.5.8 to 3.5.9, incorporating 13 fixes across DTLS, QUIC, CRLs, CMP, EC/SM2, and handshake memory safety: CVE-2026-84782, CVE-2026-35189, CVE-2026-35191, CVE-2026-42772, CVE-2026-54872, CVE-2026-54873, CVE-2026-54875, CVE-2026-72897, CVE-2026-75804, CVE-2026-75805, CVE-2026-75806, CVE-2026-77696, CVE-2026-84784.

Node 24.22.1 updates bundled c-ares from 1.34.8 to 1.34.9, resolving 11 upstream GHSAs that do not carry separate CVE IDs (GHSA-wpr3-8q3r-4q8c covers a connection-shutdown path omitted from the earlier CVE-2026-33630 fix and remains listed as No known CVE):

Frontend dependencies and code generation

In addition, go-swagger is updated from 0.33.2 to 0.36.6, resolving GHSA-8gmg-wf5j-hvf7 and GHSA-rg22-m539-jwvf (code injection during code generation when processing untrusted OpenAPI content types or enum values; first fixed upstream in 0.35.3 without a separate CVE ID). Generated files are synchronized with the updated tool. The generation process explicitly preserves the reviewed configuration-import binder and multipart consumer, retaining the existing file-size, filename and form-encoding behavior under regression tests.

Independent Go debugging modules

The standalone inspect, s3-verify, and xattr module graphs in the server repository previously lagged behind the root module. Updating their dependencies clears 37 CVE-numbered dependency findings and one non-CVE S2 advisory:

The table below links each finding to the Go vulnerability database and records the first upstream fixed version (the unfixed OpenPGP notice is listed separately under Build-stage and non-CVE advisories):

Outstanding upstream or distribution issues

As of 2026-10-23, the advisories below do not yet have an upstream or distribution release available. Rather than suppressing scanner rules, we record each finding alongside its local mitigation or runtime reachability.

Locally mitigated, awaiting upstream publication

UBI 9.8 findings without an applicable vendor fix

Scans conducted on 2026-10-22 against the SILO, mcli, and KES system-component acceptance images (containing the updated static curl and CA bundle on amd64 and arm64) each report 24 RPM findings across the same 12 unique CVEs (15 Medium and 9 Low per image, zero High/Critical, and no vendor FixedVersion). Red Hat security queries on 2026-10-23 continue to list the RHEL 9 source packages below as Affected or Fix deferred.

Because RPM scanners map advisories by source package (SRPM), defects in uninstalled CLI utilities or other CPU architectures are reported against shared runtime packages such as libgcc and glibc. The applicability of each entry is detailed below:

Build-stage and non-CVE advisories

• Alpine build-stage curl/libcurl remains 8.22.0-r0: As of 2026-10-23, the Alpine package indexes for amd64 and arm64 have not yet published 8.23.0. This host package is used only inside the temporary build stage to fetch SHA-256-pinned source archives; the runtime image ships the newly compiled static curl 8.23.0.
• GO-2026-5932: golang.org/x/crypto/openpgp is deprecated upstream with no fixed version and no CVE alias. While golang.org/x/crypto remains in the module graph, none of the target builds import the affected openpgp packages.

Historical repairs, not newly fixed vulnerabilities

Module-path binary scanners continue to match SILO against CVE-2025-27414, CVE-2026-33322, CVE-2026-33419, CVE-2026-34204, CVE-2026-39414, CVE-2026-40344, CVE-2026-41145, and CVE-2026-42600 because SILO retains the github.com/minio/minio module path and those upstream advisories specify open-ended version ranges. All eight issues were patched and verified in earlier SILO releases; see SFTP, OIDC, LDAP, replication metadata, CSV, Snowball, signature validation, and ReadMultiple.

Compatibility and dependency regression evidence

To prevent reproduced regressions in CLI table formatting, character-width calculation, and NetBSD cross-compilation, this batch pins tablewriter 0.0.5, go-humanize 1.0.1, go-runewidth 0.0.29 in the root modules, and go-systemd/v22 22.6.0 (while xattr retains its existing width-library combination). In addition:

• Kafka notification targets explicitly initialize the protocol version default to 2.1 before applying user settings;
• DARE encryption retains 32-byte keys and v2 writes while fixing buffer handling when unsealing legacy v1 payloads;
• pgzip retains the integrity check that returns unexpected EOF when a gzip checksum trailer is missing.

The October 22–23 candidate validation (built with Go 1.27.3 on both the rollback baseline and the candidate, with persisted-data acceptance run on a single-node four-drive Linux arm64 setup) passed:

• Full compilation and applicable -race and lint suites;
• Encrypted-object read and rollback verification across the old and new dependency stacks;
• Service restart, missing-shard healing recovery, and CLI output checks;
• End-to-end Console object uploads/downloads, ZIP archive previews, WebSocket sessions, and metrics charts.

The candidate sources with the October 24 dependency updates passed these additional checks:

• Full race suites for silo-pkg, mcli, and KES; API / pkg / cmd race suites for Console; the full SILO test suite and focused SFTP, IAM, and Parquet race tests. Lint, module verification, and dependency tidiness checks passed for all five projects.
• SFTP object reads, writes, listing, deletion, Unicode names, transfer block boundaries, and read-only data protection through the SILO driver against HTTP / HTTPS S3 backends. Upstream read-only server and symlink deletion regression tests passed. Both dependency baselines passed the new object-operation tests.
• JWX signature and time-claim boundary comparisons; 68 CLI output comparisons with no new differences, normalizing only existing metadata map ordering.
• Local etcd mTLS, account authentication, transactions, watches, leases, and old → new → old clients reading across server restarts; NATS / STAN message persistence, ACKs, durable subscription cursors, and reconnection.
• Local Azure / GCS protocol fixtures, KES GCP Secret Manager operations and pagination, the Azure SDK’s Arrow decoder tests, and the full upstream procfs parser fixtures. The procfs update corrects bcache units and NVMe sizes, so the corresponding metric values may change to reflect those corrections.
• Native Darwin arm64 and cross-compiled Linux amd64 builds of mcli, Console, SILO, and KES; NetBSD amd64 cross-builds of mcli and SILO.

Linux amd64 package-level Go vulnerability scans of all five projects found no affected imported packages (only the module-level GO-2026-5932 entry remains, with no imports of the affected OpenPGP subpackages).

2.2 - 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.

2.3 - silo-pkg 3.14.3 Released

Release: v3.14.3 · Source: e9d585ba1e7a. See the v3.14.2 release notes for the October dependency baseline.

github.com/pgsty/silo-pkg/v3 v3.14.3 reduces the cost of classifying admin: actions during IAM policy evaluation and is selected by Server 20261018.

AdminAction.IsValid and HasResource now perform exact map lookups before scanning the action sets: literal misses return immediately, and wildcard patterns whose prefix cannot match the admin: namespace skip the validation scan, while patterns such as adm* and a*d*m*i*n* retain their exact existing behavior.

Performance and validation

Across six alternating single-CPU benchmark runs on an Apple M5 Max (Go 1.27.2), median evaluation time for a policy with 100 non-matching bucket grants followed by a matching grant dropped from 303.2 µs to 54.4 µs (~82% reduction) with zero additional heap allocations.

Validation covered Go 1.26 and 1.27 race suites, lint, LDAP integration, vulnerability scanning, 60 seconds of equivalence fuzzing, and an exhaustive comparison across 50,000 policies and 970,020 policy evaluations against v3.14.2; mcli 20261018 also produced identical results against server builds using v3.14.2 and v3.14.3.

Adoption

Public APIs, policy formats, authorization decisions, dependencies, and the go 1.26 floor are unchanged. Server 20261018 adopts v3.14.3, while standalone mcli 20261018 and Console v2.4.2 remain on v3.14.2 (see the component matrix).

Thanks to Denis Babchuk (@botdeniska) for PR #11, and Klaus Post (@klauspost) for the original optimization.

Changes since v3.14.2

2.4 - PGSTY KES 20261018 Released

Release: RELEASE.2026-10-18T00-00-00Z · Package: 20261018000000.0.0 · Source: 2f7e741db905.

This is the first maintained PGSTY release of the Key Encryption Service (KES). KES is a standalone stateless service for SILO deployments that require external KMS-backed server-side encryption (see the component matrix).

Changes

• Establish PGSTY maintenance and release pipelines while preserving upstream copyright, attribution, and third-party licenses. The executable and system packages remain kes, and the Go module path remains github.com/minio/kes.
• Build with Go 1.27.2, refresh dependencies, and migrate the AWS Secrets Manager backend from the deprecated AWS SDK for Go v1 to AWS SDK for Go v2. Preserve YAML configuration fields, explicit credential precedence, custom endpoints, and stored key formats (continuing to ignore ~/.aws/config and SDK endpoint environment overrides).
• Preserve the KES HTTP API, MINIO_KMS_KES_* configuration settings, existing root keys, and encrypted objects so existing SILO + KES deployments can upgrade in place without key migration.
• Add upgrade, rollback, and restart integration suites pairing SILO with OpenBao KV v2 and the Moto Secrets Manager emulator, restarting SILO at each version transition so in-memory key caches cannot mask compatibility regressions.
• Ship signed Git tags, GitHub build provenance attestations, GPG-signed RPMs, and non-root container images, with the built-in kes update self-updater disabled.

Deployment and upgrade

In a server-side encryption deployment, SILO encrypts object contents, KES authenticates mTLS client requests and wraps or unwraps data encryption keys (DEKs), and OpenBao persists the root key encryption keys (KEKs). Point MINIO_KMS_KES_ENDPOINT at KES, not OpenBao (see the KES and OpenBao design note for architecture boundaries and recovery requirements).

Configure TLS certificates, mTLS client identity policies, and a persistent key store before starting KES in production (development mode stores keys only in memory). Official containers run as non-root UID/GID 1000:1000, so mounted configuration files and certificates must be readable by that user; Linux RPM/DEB/APK packages install /usr/local/bin/kes without starting an unconfigured service.

Back up your key store and configuration before upgrading, then verify decryption of existing objects, creation of new encrypted objects, and cold readback after restarting both KES and SILO.

Delivery and validation

All 19 release assets (6 Linux/macOS/Windows amd64/arm64 archives, 6 Linux RPM/DEB/APK packages, an archive checksum manifest, and 6 package checksum sidecars) were verified across downloaded digests, binary source/platform stamps, package payloads, both RPM signatures, and 11 GitHub build attestations (release workflow).

The official multi-arch (linux/amd64 and linux/arm64) container image docker.io/pgsty/kes:RELEASE.2026-10-18T00-00-00Z (Docker publication run) has index digest:

sha256:c2d1a63d15052dfd2854bec9db3fc6846dd74fd6fdf43079f338f36e7a3d5f04

The primary verified integration stack is SILO + PGSTY KES + OpenBao KV v2 (covering mTLS authentication, OpenBao AppRole access, DEK wrap/unwrap, restart persistence, unauthenticated request rejection, and interoperability/rollback matrices across SILO 20260903/20260916 and upstream KES 2025-03-12T09-35-18Z, with AWS Secrets Manager protocol and storage regression coverage via Moto).

Download KES · Configuration and installation · Artifact verification · Changes since upstream.

2.5 - SILO Console 2.4.2 Released

Release: v2.4.2 · Source: ef2dd2c41d21.

Console v2.4.2 ships both as a standalone release and as the embedded Console in Server 20261018 (see also the silo-pkg v3.14.2 release notes).

Changes

• Adopt mcli 20261018, silo-pkg v3.14.2, and upstream minio-go v7.4.1. The SDK cleans up failed multipart uploads after cancellation, formats retention timestamps in UTC, and preserves requested STS durations (parallel GET and ComposeObject remain opt-in).
• Preserve wrapped S3 error codes during bucket-versioning operations so attempting to suspend versioning on an Object Lock bucket surfaces InvalidBucketState cleanly.
• Build with Go 1.27.2 and Node 24.22.0 LTS. Refresh golang.org/x/* modules alongside compress v1.20.3, msgp v1.6.5, etcd v3.7.2, fwd v1.2.1, and cpuid v2.4.1 (retaining go-systemd v22.6.0 for NetBSD and tablewriter v0.0.5 for MC API compatibility).
• Pin GoReleaser v2.18.3, golangci-lint v2.15.0, and govulncheck v1.9.0, rebuild embedded frontend assets as Console 2.4.2, and update pinned container build stages.

Integration

Because the retained module path has no /v2 suffix, Go consumers reference Console v2.4.2 via pseudo-version v0.0.0-20261017112417-ef2dd2c41d21. An embedding Server must declare both Console and MC replacements explicitly:

replace github.com/minio/console => github.com/pgsty/silo-console v0.0.0-20261017112417-ef2dd2c41d21
replace github.com/minio/mc => github.com/pgsty/mc v0.0.0-20261017101407-fa3b8bf72458

Console v2.4.2 requires github.com/pgsty/silo-pkg/v3 v3.14.2 (see the password-permission migration guide). Note that the go-jose v4.1.6 4096-bit RSA JWK limit applies only to Server OIDC paths that import go-jose; neither go-jose nor go-ldap is linked into the standalone Console binary.

Delivery and validation

All 44 release assets (6 platform binaries, 6 archives, 9 Linux packages, checksum manifests, SBOMs, and signed provenance attestations) were verified against tagged commit ef2dd2c41d21. The commit passed the full CI matrix (permissions, SSO, replication, browser tests, source-image equivalence, and reproducible packaging), vulnerability checks, the local Go race suite, 251 frontend unit tests, and live API/browser sharing checks against Server 20261018.

The published docker.io/pgsty/silo-console:v2.4.2 multi-arch (linux/amd64 and linux/arm64) manifest digest is:

sha256:4cf47061e0d2f249df3c1cd2a939966ff3c69cc3cf7d10a7b1b39d5c110ae999

Release verification contract · Component matrix · Changes since v2.4.1.

2.6 - mcli 20261018 Released

Release: RELEASE.2026-10-18T00-00-00Z · Package: 20261018000000.0.0 · Source: fa3b8bf72458.

mcli 20261018 ships both as the standalone CLI client and as the coordinated client module in Server 20261018 and Console v2.4.2 (see also the silo-pkg v3.14.2 release notes).

Changes

• Adopt silo-pkg v3.14.2 and upstream minio-go v7.4.1. The SDK cleans up failed multipart uploads after cancellation, formats retention timestamps in UTC, and preserves requested STS durations while retaining existing CopyObject embedded-error and checksum handling (parallel GET and ComposeObject remain opt-in).
• Build with Go 1.27.2. Refresh golang.org/x/* modules, compress v1.20.3, msgp v1.6.5, and etcd clients v3.7.2 (with fwd v1.2.1 fixing reads that return bytes alongside an error as well as Skip offsets, and cpuid v2.4.1 fixing cache detection).
• Pull in go-jose v4.1.6 (fixing excessive CPU usage on oversized RSA JWKs in GHSA-mgcc-cww5-fp2q) and LDAP v3.4.15 via silo-pkg.
• Refresh pinned UBI 9 base images and release tooling: GoReleaser v2.18.3 (including log secret redaction and archive fixes), nFPM v2.48.0, golangci-lint v2.15.0, govulncheck v1.9.0, and gofumpt v0.12.0.

Upgrade

CLI commands, aliases, MC_* environment variables, and configuration formats are unchanged (retaining the go-systemd v22.6.0 replacement for NetBSD builds and tablewriter v0.0.5). See the component matrix for version pairings.

docker run --rm docker.io/pgsty/mc:RELEASE.2026-10-18T00-00-00Z --version

Delivery and validation

All 19 release assets (6 Linux/macOS/Windows amd64/arm64 archives, 6 Linux RPM/DEB/APK packages, an archive checksum manifest, and 6 package checksum sidecars) were verified across downloaded digests, 6 binary source stamps, 6 package payloads, PGSTY GPG signatures (9592A7BC7A682E7333376E09E7935D8DB9BD8B20), and 11 GitHub build attestations bound to fa3b8bf72458.

The tagged commit passed Go unit tests, cross-compilation, vulnerability scanning (zero reachable or imported-package vulnerabilities; the unused OpenPGP module-only advisory GO-2026-5932 remains), and live Go/Shell TLS functional suites against SILO fbcb5119782a (release build · Docker publication).

The published docker.io/pgsty/mc:RELEASE.2026-10-18T00-00-00Z (and latest at publication) multi-arch (linux/amd64 and linux/arm64) manifest digest is:

sha256:6ecdaec70bc5e8cf9d0e9a70c190f3beb1c83f11617ff4333f1fcd71ab1daf18

Download and installation · Full changelog · Changes since 20260916.

2.7 - silo-pkg 3.14.2 Released

Release: v3.14.2 · Source: c6835145176f.

github.com/pgsty/silo-pkg/v3 v3.14.2 provides the October dependency baseline for mcli 20261018 and Console v2.4.2; follow-up patch v3.14.3 adds an admin-action classification optimization used by Server 20261018.

Changes

• Update upstream minio-go to v7.4.1: clean up failed multipart uploads even after caller context cancellation, serialize Object Lock retention timestamps in UTC, preserve requested STS durations, and support projected Kubernetes service-account token files (parallel GET and ComposeObject remain opt-in).
• Update go-jose to v4.1.6: fix excessive CPU consumption when parsing oversized RSA JWKs (GHSA-mgcc-cww5-fp2q); update LDAP to v3.4.15, msgp to v1.6.5, and etcd clients to v3.7.2.
• Refresh golang.org/x/*: x/crypto v0.58.0, x/net v0.61.0, x/sys v0.49.0, and x/text v0.43.0. Built and tested with Go 1.27.2 while retaining the go 1.26 module floor and the go-systemd v22.6.0 NetBSD replacement.

Compatibility and adoption

require github.com/pgsty/silo-pkg/v3 v3.14.2

Public package signatures and password-policy semantics are unchanged (see the password-permission migration guide when upgrading from before v3.14.0, and the component matrix for version pairings).

Behavioral notes:

• go-jose v4.1.6 rejects RSA JWKs larger than 4096 bits; verify identity-provider key sizes in OIDC/JWKS consumers.
• STS durations below one hour are now sent as requested rather than silently clamped by the client, so invalid short durations will be rejected by the server.

Validation

The release passed full lint and race suites under Go 1.27.2, race tests under Go 1.26.9, OpenLDAP integration tests, module tidiness checks, and govulncheck scanning (zero reachable or imported-package vulnerabilities).

Tagged-source CI runs: Go, LDAP, VulnCheck.

Changes since v3.14.1 · PR #10.

2.8 - SILO 20261015: Superseded Draft Record

Status: Superseded by Server 20261018. RELEASE.2026-10-15T00-00-00Z was briefly published at 2026-10-15 13:52:28 (UTC+8), then reverted to Draft and superseded by Server 20261018, which includes the complete October repair and component stack. This page archives the candidate source scope and acceptance test results; use 20261018 for all deployments and upgrades.

• Historical tag: RELEASE.2026-10-15T00-00-00Z
• Package version: 20261015000000.0.0
• Candidate source: 7a3ca0f82100cce06289a465f54139da2639f642 (full diff against Server 20260916)

Object Lock repairs

• SN-2026-015 — Retention authorization (#234): every PutObjectRetention request requires s3:PutObjectRetention, evaluated with request-body Object Lock condition keys before reading object state. Shortening, clearing, or changing the mode of active GOVERNANCE retention additionally requires the explicit bypass header and s3:BypassGovernanceRetention (which does not override a Deny on s3:PutObjectRetention). Clearing retention evaluates remaining days as 0, and distant future dates no longer saturate duration arithmetic.
• SN-2026-016 — Protected version writes (#235): caller-selected write versionId parameters require trusted replication credentials (s3:ReplicateObject). Directory null versions and persisted multipart targets are checked under the destination write lock before overwrite (including uploads initiated before upgrading or recovered from legacy staging state), enforcing active GOVERNANCE, COMPLIANCE, and legal-hold protections; unreadable lock metadata fails closed.
• Release gate (#237): the release workflow runs the Object Lock race regression suite as a build prerequisite, covering slow-body directory overwrites, preflight read failures, legacy multipart completions against COMPLIANCE, and recovered-upload UUID collisions.

See the security advisory and repair design for full details.

Other changes since 20260916

Component identities

Upgrade requirements

1. Upgrade all writers and replication peers: upgrade every Server node and all replication sites accepting S3 writes so unpatched peers cannot accept unauthorized retention changes or in-place overwrites.
2. Review retention policies: policies granting s3:BypassGovernanceRetention without s3:PutObjectRetention, or relying on bypass to evade retention condition keys, now receive 403 AccessDenied.
3. Caller-selected versionId restriction: ordinary S3 writes (including root-signed requests) cannot specify a target versionId; trusted replication preserves version IDs, and mcli batch replicate into SILO requires s3:ReplicateObject on the destination credentials.
4. Fail-closed lock checks: locked directory objects and locked multipart targets cannot be overwritten; if lock metadata is unreadable, restore drive health before retrying.
5. Audit historical state: review prior audit logs for unexpected retention changes before the upgrade (when upgrading from releases prior to 20260916, also follow the September upgrade requirements).

Candidate artifact acceptance

The following CI workflows and verification checks passed against 7a3ca0f82100cce06289a465f54139da2639f642:

• Static artifact verification: verified all 36 release assets, 34 build provenance attestations, static version/commit identities across all 6 Linux/macOS/Windows amd64/arm64 binaries, payloads across all 6 RPM/DEB/APK packages, and both RPM signatures (see historical archive checksums and package checksums).
• macOS arm64 runtime acceptance (110/110 passed):

(Across those runs, all 65 rejected operations left the complete target object state unchanged; Windows and macOS amd64 binaries were verified statically.)

Docker images

Docker publication run 38689158028 built and attested the multi-platform (linux/amd64 and linux/arm64) images from the same release commit:

All four platform-specific images (whose /usr/bin/silo binaries matched the official Linux archive binaries byte for byte) passed /minio/health/ready probes and the full Object Lock API suite (196/196 passed, with all 120 rejected operations preserving object content, version identity, ETag, retention, legal hold, and version listings):

Combined with the native macOS arm64 installation and upgrade suite, candidate runtime acceptance passed 306/306 checks.

2.9 - SILO Console 2.4.1 Released

SILO Console v2.4.1 was released on September 16, 2026 from 1360e26d976d. It integrates pkg v3.14.1 and mcli 20260916, restricts the anonymous sharing proxy, streams multi-object ZIP downloads and adds signed, traceable release artifacts.

Shared downloads

The fix for #52 restricts the anonymous proxy to object-content GET requests at the configured S3 origin. It rejects redirects, system paths and query-selected operations that are not object downloads. Public objects, presigned links and version-specific downloads continue to work. No new sharing-disable environment variable is needed.

Thanks to Jiri Pejchal (@jiri-pejchal) for reporting the internal-metrics exposure. See the sharing boundary for the supported request forms and reverse-proxy requirements.

Password-policy migration

This patch release includes an authorization change. The Change Password button and session capability use admin:ChangeMyPassword; creating users and resetting another user’s password continue to use admin:CreateUser. With the matching SILO Server, denying CreateUser alone no longer locks the caller’s own password. To retain that restriction, deny both actions in the same statement before upgrading, keeping its original scope and conditions.

The updated built-in readonly permits self-service password changes and no longer overrides a separate CreateUser Allow. Saved policy overrides retain their stored statements. Upgrade Server, Console and pkg together and review the migration and rollback guide.

Downloads and browser recovery

• Multi-selection ZIP downloads stream to a file writer when the browser supports it, with backpressure, cancellation and duplicate-transfer protection. Other browsers hand the download to their native download manager. Neither path buffers the complete ZIP in JavaScript.
• Progress uses a percentage only when the response supplies a reliable total. The native fallback identifies the handoff explicitly; cancellation then belongs to the browser’s download manager. Selections over 5 GiB or with an unknown total recommend mcli for long-running transfers.
• Invalid routes and rendering failures offer recovery without clearing preferences. English and Chinese labels, icon controls, sign-out text and keyboard-accessible tooltips are completed.

Dependencies and embedding

The SDK handles S3 errors embedded in HTTP 200 CopyObject responses; JWX fixes custom JSON field-name escaping and strfmt updates hostname validation for Go 1.27. The embedded frontend and third-party credits are regenerated from this dependency graph. go-systemd v22.6.0 and tablewriter v0.0.5 remain intentional compatibility pins.

Go embedders select Console as github.com/pgsty/silo-console v0.0.0-20260916075814-1360e26d976d through the historical github.com/minio/console module replacement. Go does not inherit dependency replacements: copy the explicit MC replacement from the tagged README. The supported administration target is the coordinated SILO stack; upstream MinIO/MC compatibility is best effort.

Packages and verification

The GitHub Release contains 44 assets: binaries and bundles, DEB/RPM/APK packages, source, legal notices, SPDX SBOMs, a checksum manifest and its Sigstore bundle. Checksums use Cosign signatures, and provenance records the tagged workflow inputs.

For standalone v2.4.1 deployments, use the GitHub Release binaries or Linux packages; multi-architecture Docker Hub images on docker.io/pgsty/silo-console are available starting with Console v2.4.2. Server-embedded Console is unaffected.

Linux packages retain minio-console.service, console-user and /etc/default/console. The service now uses /var/lib/silo-console for state, /etc/silo-console/certs for certificates, and a 90-second shutdown limit. Before restarting an existing installation, migrate certificates with the documented ownership or retain the old path through CONSOLE_OPTS. The installer preserves old certificates and keys and does not restart the service for you. See the package upgrade instructions.

The exact release source passed the complete CI matrix, vulnerability checks and release verification. Local validation also covered 251 frontend unit tests, 51 browser tests, byte-identical embedded assets and sharing in standalone and embedded deployments. The downloaded Darwin/arm64 executable was independently checked against the signed checksum manifest and exercised against a SILO test server.

2.10 - silo-pkg 3.14.1 Released

v3.14.1 was published from fa657ef4. This is a dependency and tooling release of github.com/pgsty/silo-pkg/v3; the diff from v3.14.0 changes no package Go source or public API.

Dependency changes

• JWX advances from v3.2.0 to v3.3.0. The vendor’s release notes identify GHSA-4cf7-xm37-g63h: custom JSON field names must be escaped during encoding. Reachability depends on accepting attacker-controlled custom claim names; this package’s env JWT path uses registered claim names.
• Upstream minio-go advances to v7.3.1-0.20260915093545-32e1f32cb176, including minio-go #2306: recognize an S3 CopyObject error embedded in an HTTP 200 response instead of reporting a successful copy.
• Testify advances to v1.12.1 and the lint configuration adopts gomodguard_v2. The Go 1.26 floor, Go 1.27.1 toolchain and go-systemd NetBSD replacement remain.

Component and migration boundary

The v3.14.0 password-policy change remains in force; this patch does not revert it. Preserve the paired admin:CreateUser / admin:ChangeMyPassword Deny where that was the intended restriction, using the migration guide.

SILO 20260916, mcli 20260916, and Console 2.4.1 select this package; see the component matrix.

Release verification is recorded in the linked release and PR #9.

2.11 - SILO 20260916 Release Notes

Version date: 2026-09-16 · Published: 2026-09-16 UTC (September 17 in China) · Tag: RELEASE.2026-09-16T00-00-00Z · Package version: 20260916000000.0.0. Use the download page for installation.

The source range runs from released commit 9b11dc9469e6 to released 2a4d51406b7e: 210 commits, including 140 non-merge commits. These notes describe the final behavior, including the listing-quorum, version-purge and migration-tag repairs after #214.

Highlights

• Stronger request authentication: reject unsigned operation headers in ordinary and presigned SigV4, verify presigned body hashes, and use authenticated inputs for signature-age and payload-hash policies.
• Durable IAM revocation: retain deletion revisions, parent revocation boundaries and membership grant times across delayed events, same-name recreation and restart/recovery.
• One logical object across pools: coordinate conditional PUT, multipart completion, conditional DELETE, addressed-version deletion and metadata updates under consistent selection and locking rules.
• Preserve tags during pool migration: rebalance and decommission retain tags, their original revision and ordered empty states for ordinary and multipart objects.
• Correct encrypted and federated copies: preserve raw SSE-C replicas, plaintext part sizes, independently ordered lock/tag metadata, and the checksum, version and time of the actual destination write.
• More reliable replication and configuration convergence: repair tag resurrection, marker purge/MRF recovery, resync counters/cancellation, and bucket metadata source timestamps and deletions.
• Opt-in durable multipart discovery: add persistent scanning, global pagination and read-only preflight. Legacy remains the default; capacity and late-creation-write limitations remain explicit.
• Updated administration stack: select Console 2.4.1, mcli 20260916 and pkg 3.14.1, including bounded browsing, streaming ZIPs, reliable failure exits and policy correctness fixes.
• Two upgrade requirements need advance preparation: password permissions change the meaning of existing policies, and durable IAM revocation requires coordinated upgrades and complete backend backups.

Versions and components

The release explicitly replaces Console and MC with v0.0.0-20260916075814-1360e26d976d and v0.0.0-20260916070421-e952aa78f10a. Go does not inherit a dependency’s replacements. The shared package uses the PGSTY module path directly; Server, Console and MC retain their historical module identities and protocol names. minio-go/v7 continues to use a verified upstream revision.

The supported release stack is SILO + Console + mcli + silo-pkg; compatibility with unmodified upstream MinIO/MC remains best effort.

Security and authorization

This cycle includes four local security identifiers. SN- identifiers are project tracking IDs, not CVEs. See the signed-header contract and September security notes.

Related changes remove ambiguous duplicate replication-source headers, derive s3:signatureAge from the signed date rather than a scratch header, align presigned query/header payload-hash precedence, and inject the server-generated PutObjectTagging header after authentication but before authorization. X-Amz-Content-Sha256 may remain outside SignedHeaders because its effective value is separately bound and checked. Explicitly signed UNSIGNED-PAYLOAD retains its meaning.

Streaming SigV4 seed operation headers remain outside this check. Unsigned-header rejection returns 400 AccessDenied. The Console fix adds no global sharing-disable variable and continues to enforce S3 authorization.

Password permission split: a compatibility change

Server #175, pkg #6 and Console #51 separate password self-service from user administration:

• An internal user changing their own password checks admin:ChangeMyPassword, allowed unless explicitly denied.
• Creating users or resetting someone else’s password still requires admin:CreateUser. Existing root, STS and service-account restrictions remain.
• A standalone CreateUser Deny no longer locks the caller’s password. An existing ChangeMyPassword Deny now constrains this endpoint.
• Updated built-in readonly no longer overrides a separate CreateUser grant with its own deny; the package also supplies the separate consolereadonly capability policy. Saved policy overrides are not rewritten.

To retain the old combined restriction, deny both actions in the same statement before upgrading, preserving its resources and conditions. Keep both denies during rollback: an old Server cannot enforce a password-only deny on this endpoint. See password migration.

Shared policy correctness

pkg #4 fixes statement deduplication that omitted NotResource from hashing or collapsed distinct string-condition sets, potentially discarding Deny clauses. Directly constructed policies report Deny before indexing. Multi-star wildcard matching no longer uses exponential recursion while retaining byte matching and historical MatchSimple boundaries.

Requests that relied on lost denies may now be rejected. If a clause has already disappeared from stored JSON, upgrading cannot reconstruct it: compare with the original policy and reapply it.

IAM replication, revocation and recovery

Deletion revisions remain in the original IAM paths for users, service accounts, groups, policies and policy mappings. Normal listing and authorization hide deleted records. Object and etcd backends serialize revision comparison and persistence, retain source timestamps, and prefer deletion over a live record at the same timestamp.

• Delayed same-backend deletion notifications reload committed storage rather than deleting a subsequently recreated identity.
• Recreated parents retain RevokedBefore; new service accounts and internal STS credentials carry a signed siloParentRevocation boundary. Replaying or editing an old child does not renew its authority.
• Each group member retains its own grant time. Editing another member or group status does not regrant every member.
• Newer service-account snapshots can replace an older copy of the same key while preserving secrets, disabled state, absolute expiration and revocation boundaries. Credential-type conflicts fail; expired snapshots cannot extend old credential life.
• Healing resumes after leadership is regained, retains acknowledgements and retries bounded batches. Natural expiration of ordinary STS credentials does not automatically create permanent deletion history; reusable service-account keys retain revisions.
• IAM metrics report retained revocations, healing failures, duration and last success. See the design and metrics.

Cross-site revocation propagates asynchronously. A parent deletion commits before secondary cleanup; if cleanup returns HTTP 500, the parent revocation is already in effect. Tombstones have no TTL or automatic compaction, and storage/startup costs grow with retained history. Concurrent independent membership edits, equal-time conflicting live updates, arbitrary clock skew and cross-site individual-token revocation retain documented limits.

S3 conditions and multi-pool consistency

The coordination layer selects a logical object under a shared namespace lock before evaluating conditions or merging copies of the same version. Relevant draining pools participate. Retention, legal hold and tags each use their own revision; object modification time is not a version for every metadata field.

Availability tradeoff: unverifiable metadata in another relevant pool can fail conditional PUT/completion or coordinated deletion even when another pool serves GET/HEAD. Read-quorum failures return 503; restore readability before retrying. Cleanup can fail after partial physical mutation; there is no distributed rollback. Pending outbound delete replication retains versions until purge completes.

A public conditional PUT with a destination versionId compares the current object while preserving the requested write version. It does not clean stale copies, reverse previously accepted overwrites or provide global clock ordering. Multipart #190 and ordinary PUT #207 address separate defects.

Unsupported boundaries: batch DeleteObjects XML ETag still provides no condition protection. Empty If-Match follows ordinary deletion; internal recursive prefix deletion bypasses object conditions. There is no s3:if-match policy key or new GetObject authorization requirement. Use the supported single-object path when conditions matter. See conditional DELETE and multi-pool consistency.

Preserve object tags during pool migration

fced8630365f repairs lost object tags during rebalance/decommission. The read representation stores tags separately in ObjectInfo.UserTags; forwarding UserDefined alone could omit the canonical tag field needed by the destination write.

The four ordinary-PUT and multipart-initialization entry points now rebuild that field in an independent metadata copy. They preserve the original tag revision, including absent/empty revisions and ordered empty states, without generating a new revision or mutating the reader’s map. Writes and multipart completion retain existing rereads under the coordination lock so an old reader does not override a later tag update or removal.

The patch does not recover tags lost during earlier migrations. Audit previously migrated objects and tag-dependent policy and lifecycle rules separately.

Null-version listing quorum

8d06424b1 prevents a newer minority from hiding an older null version that has listing quorum. It recounts per header only when the original selection lacks quorum, every nonempty drive stream has exactly one ordinary null version, and all share the same erasure layout. Mixed version histories retain their previous behavior.

Remaining limitation: #218 tracks successful listings that still omit readable objects during rolling restarts with concurrent overwrites. Do not run synchronization tools that delete destination objects based on such listings; list again after the cluster stabilizes.

Encryption, checksums and object attributes

• Raw SSE-C replicas: store authorized replica ciphertext verbatim, avoiding another encryption/compression pass caused by destination defaults (#109, #122).
• Plaintext multipart sizes: preserve logical part lengths in replicas, repairing part-number/range reads, object size after replacement and attributes (#119, #124).
• No new compressed SSE-C objects: exclude ordinary PUT, multipart initialization, COPY and Snowball SSE-C writes from compression. SSE-S3/KMS retain their encryption-compression options (#118, #126).
• Retransmission repair: update existing or undecodable SSE-C replicas through object retransmission instead of ordinary metadata COPY, preserving newer destination retention/hold (#120, #134).
• Explicit checksums during key rotation: perform the required full rewrite, including requests for the existing algorithm. A multipart source may become a single-part destination and its ETag may change (#113, #123).
• Logical attributes: GetObjectAttributes returns plaintext part sizes for compressed/encrypted objects and terminates pagination correctly with sparse part numbers (#114, #115, #128).
• Honest unreadable-object errors: return 500 for integrity/decryption failures instead of a 206 accepted as a successful read (#110, #121).
• Chunked checksum interoperability: honor and validate the actual checksum header on non-trailer chunked PUTs even when x-amz-trailer is advertised (#107, #143).

These prevent new errors and provide supported repair paths; they do not rewrite historical encrypted data. Retain keys and exact version identities when auditing compressed SSE-C, wrong part sizes or unreadable replicas. See SSE-C integrity.

Federated CopyObject

This section concerns remote forwarding in legacy etcd bucket federation, rather than bucket/site replication. Changes accumulate through #157, #159, #163, #172, #177 and #179.

Issues: #99, #100, #158, #166–#171. A remote write may have committed before response validation fails; inspect the actual destination version before retrying a versioned copy. See the federated copy contract.

Object Lock, tags and replication recovery

Independent lock and tag ordering

• An ordinary write supplying only legal hold no longer suppresses bucket default retention; ON and OFF do not substitute for retention selection, and explicit timestamp precision is retained (#165, #177).
• Empty-value and timestamp-only retention/hold removals participate in ordering, preserve newer destination state and no longer cause endless retransmission (#111, #117, #129, #131).
• Replica writes reconcile authoritative Object Lock state across pools, extending the earlier single-set boundary (#133, #178).
• Pool reconciliation carries tags with their revisions; SSE-KMS metadata COPY and SSE-C rotation retain tag timestamps. Local PUT/DELETE tagging advances revisions monotonically, and empty tags are ordered deletions rather than missing state (#189, #193, #196).

Both replication endpoints need the fixes to respect empty-tag tombstones. Explicit resync/heal adds a metadata COPY for objects with recorded tag revisions; destination default KMS can make that operation rewrite data. Tag-filtered rules still evaluate target eligibility using the post-deletion empty tags. Missing or malformed historical revisions are not reconstructed. See Object Lock ordering and replicated tag ordering.

Delete markers, MRF and resync

• Correct single-object marker-purge classification and retain marker identity/retry state through workers, scanner/heal and persistent MRF recovery. Accept a relevant 405 marker response only when bucket, key, version and modification time match. Normalize purge audit status from COMPLETE to COMPLETED (#153, #162, #196).
• Expose bounded MRF queue drops through administration, metrics and deduplicated logs, and align object/delete worker allocation. This does not turn the bounded queue into a lossless unbounded queue (#152).
• Persist final counters before publishing resync Completed; count success by the actual replication outcome rather than the existence of a target object (#136, #139).
• Dispatch only to the resync target ARN. Give each resync ID an independent cancellation context, drain blocked dispatch/walkers/workers, and prevent older work from overwriting terminal state (#141, #137).

Exact-version purges and queued creation

eb4f5e5b3 stops a pure version purge from creating markers on drives that lacked them. Missing-version retries require write-quorum absence; purge results combine removed and reliably absent replies. Receivers resolve the addressed version across pools, and marker healing preserves stored replication and purge metadata.

254b19ac0 rereads queued marker creations under the replication lock. A missing version, non-marker version or version under purge makes the task stale; an uncertain read is retried through MRF. The check covers tasks queued by the DELETE handler, GET/HEAD/LIST healing, scanner and MRF.

358ab38fb reports a delete marker only for a stored marker, preventing a data version awaiting purge from incorrectly returning x-amz-delete-marker: true and producing the wrong removal event.

Remaining limitations: creations already in flight, replays from another site, and minority residue after a crash following a majority-acknowledged purge remain tracked in #217. This is not a persistent receiver-side purge fence.

Replica metadata normalization

Restore only six replication-specific fields after ordinary metadata extraction, preventing transport-only aws-chunked from becoming stored Content-Encoding. Trusted Snowball entries no longer inherit ordinary metadata from the outer archive (#185, #194).

These changes do not scan/rewrite existing objects or recover lost tags, lock history or every unfinished purge. Use the read-only audit tool and runbook to inspect exact versions, mixed encodings, ambiguous findings and controlled recovery rather than running bulk self-COPY.

Bucket configuration, caches and startup

PR #180 completes source-state convergence for #77. Policy, Tags, SSE, Quota, Versioning and Object Lock read/compare/mutate/save under the same metadata.lock. Peer events retain source time; local changes advance monotonically past retained time. Equal-time deletions win, and stable content keys resolve other conflicts.

• Dedicated events, bulk, import, initial synchronization and heal use the same rules. Omitted fields leave existing settings unchanged; empty Versioning/Object Lock events still do not delete those settings.
• Canonical policy JSON allows accepted NotAction/NotResource policies to be retrieved/exported. Statement/set order may change without changing authorization.
• Empty Policy retains deletion semantics. Zero Quota remains a live document imposing no capacity limit, rather than silently becoming a different deletion state.
• Missing historical bucket Created values can be recovered from physical information and persisted. Adoption does not turn empty defaults into deletions, and unknown/invalid/unreachable sources receive bounded diagnostics.
• MINIO_SITE_REPLICATION_METADATA_TOMBSTONES is off by default. Upgrade every participating site before enabling it consistently and restarting, exposing empty-payload Tags/SSE/Quota deletion times to heal/initial sync. Missed-deletion convergence remains limited while it is off.

Historical receive-time pollution is not automatically rewritten, and rolling downgrade across the new persistent IAM state remains unsupported. See bucket metadata convergence.

Other fixes close remaining bucket deletion/update/lifecycle/cache publication races, remove the reload guard that mistook the maximum field timestamp for a whole-record version, and preserve per-bucket CORS through metadata export/import (#105, #112, #127, #156, #164).

#116 adds startup-readiness documentation and Linux restart evidence. Verify readiness with signed PUT/GET requests at each coordinator in addition to health probes.

Multipart discovery, pagination and cancellation

PR #198 adds durable discovery; #213 restores conservative defaults and rollback compatibility. The final default in 20260916 is legacy. (SILO 20261018 4733e1423 subsequently retired MINIO_API_MULTIPART_LISTING=strict and kept legacy cache/exact-key listing as the sole public mode; see the latest decision.)

New writers record reserved bucket/key identity in the existing quorum-written xl.meta and remove upload-only fields on completion. There is no secondary index or directory migration. The shared maxUploadsList request limit decreases from 10,000 to 1,000 in both modes. This bounds the accepted page-size parameter; the legacy cache path can still return more entries because it ignores pagination.

Enable strict only through process environment MINIO_API_MULTIPART_LISTING=strict and restart; mcli admin config set is not supported. Invalid values diagnose and fall back to legacy while retaining other API settings. First upgrade every writer, drain legacy uploads, run the read-only GET /minio/admin/v3/multipart-preflight endpoint with admin:StorageInfo, and validate capacity. Unidentified legacy uploads can block strict lists for other buckets.

Each process admits two scans; each scan has 16 identity workers, four metadata workers, a 30-second context and a 100,000 aggregate directory-entry budget (counted across drives, so 100,000 directory entries rather than 100,000 unique uploads). Every page rescans persistent state. Exhaustion or uncertain coverage returns 503 rather than a successful partial page. A temporary 10,000-upload/four-APFS-volume experiment took 18.7 seconds for one page, missing the provisional five-second target.

Both modes fix wrong-key/bucket Abort evicting a valid upload’s cache and peer notification cancellation after unlocking. HTTP retains idempotent 204 for an absent upload. Late physical creation writes can still restore an upload after acknowledged cancellation; no durable creation fence was added. #79 therefore remains open. See the enablement and rollback contract.

Cumulative Console 2.4.1 improvements

Beyond sharing and password permissions, the embedded selection includes these post-20260903 changes:

• Cursor browsing: ListObjectsV2 pages of 50/100/250/500/1000 entries, with explicitly page-scoped filtering, sorting and selection; no full-bucket count scan. Failed page changes preserve the current listing, cancellation releases list workers, and rewind discloses row/time limits. Empty/null versioning responses no longer crash the list.
• Exact operation identity: retain bucket/key/version for deletion and constrain directories to their trailing-slash prefix. Lifecycle edits preserve current/noncurrent, date-based and unexposed settings, read legacy prefixes and remove stale filter representations. Replication-rule deletion retains shared targets and uses configuration deletion for the last rule. Governance bypass is explicit and off by default for authorized users, including object-only retention.
• Capabilities and sessions: gate Create Bucket on s3:CreateBucket; preserve sessions after background transport failures; URL-encode Watch filters and preserve structured Inspect errors without consuming bodies twice.
• Embedded compatibility: restore loopback TLS login, apply embedded local-proxy trust only to an explicitly initialized TCP loopback peer, retain standalone trust-none defaults, and forward all four WebSocket limits instead of incorrectly capping public browsing at eight connections per source (Server #108, #147, #148).
• Streaming ZIPs: use a backpressured, cancellable file writer where supported and native download management elsewhere, without buffering whole archives in JavaScript. Native handoff cancellation belongs to the browser. Show percentages only with reliable length and recommend mcli above 5 GiB or when size is unknown.
• Recovery/localization/accessibility: recover from malformed routes, persisted preferences and render errors, and complete English/Chinese labels, icon names, sign-out text and keyboard tooltips. Shared dropdowns no longer select a stale hovered item after a quick click/touch, or select another value when clicking a disabled item.
• Standalone packages: improve reproducibility, immutable tooling/browser inputs, SBOMs, signatures and provenance. Preserve minio-console.service, console-user and /etc/default/console; move certificates to /etc/silo-console/certs with explicit migration instructions. Installation does not automatically restart the service.

References: Console #47, #50, #57, 2.4.1 notes.

Cumulative mcli 20260916 improvements

The bundled client includes both 20260913 and 20260916 changes:

• Pipe honors applied global quiet/JSON settings, avoids progress frames on redirected output, preserves explicit checksums for empty input and streams nonempty input. MC_* booleans accept on/off/enabled/disabled.
• SQL/S3 Select, transfers, mirror permission errors, legalhold, partial recursive retention failures and mv source-deletion failures return nonzero. Mv waits for deletion results without rolling back successfully copied destinations.
• Per-object mirror permission errors do not stop later objects; finite failed jobs exit 1 and do not print an ordinary successful completion summary. Explicit JSON summaries report failure, and very short transfers retain finite speed values. Existing listing/watch cancellation-retry boundaries remain.
• Mirror –remove –watch preserves targets when historical source versions are deleted. Administrative dry runs never fall back to a real restart; non-TTY results remain reliable.
• Empty retention durations and invalid find –regex expressions report errors instead of panicking; JSON usage errors retain valid output contracts.
• The SDK detects CopyObject errors embedded in HTTP 200, preventing mv from deleting its source after false copy success. This applies when the client selects CopyObject, normally below 64 MiB or with –disable-multipart, while the default large-object path uses ComposeObject.

Scripts must inspect the final exit status rather than initial success messages or progress bytes. Skip-errors does not turn an observed failure into exit 0; some retention JSON failures may lack readable error text. Commands, aliases, MC_* variables, configuration format and package naming remain compatible.

HTTP, TLS and observability

• Absolute header deadline: #196 wires –read-header-timeout / MINIO_READ_HEADER_TIMEOUT into the server and prevents small reads from indefinitely extending HTTP/1 header parsing. The default is 30 seconds. Bodies retain rolling idle timeouts. Shorter values constrain TLS handshake reads; HTTP/2 retains its independent behavior. TLS writes and handler CPU/storage waits do not gain a new total deadline. Negative values disable the header-specific limit and are not recommended. The design responds to #183.
• Go TLS defaults: remove eight explicit Server curve overrides so listeners, nodes, identity providers, replication and etcd honor Go 1.27 defaults and applicable GODEBUG controls without weakening certificate/hostname checks (#164). This changes what SILO sends and accepts on the wire. With no GODEBUG set, the offered group list becomes Go’s current default, which additionally includes SecP256r1MLKEM768 and SecP384r1MLKEM1024; with GODEBUG=tlsmlkem=0 set, that switch now actually takes effect — process-wide, and on the inbound listener as well as outbound connections. #154 is closed, though the reporter’s 2026-09-17 retest on this release still failed; total discovery/JWKS timeouts remain separate work. See TLS/OIDC and pinned TLS parameters and handshake compatibility.
• CPU metrics race: locking around both map levels read by loadCPUMetrics prevents concurrent resource updates and Prometheus scrapes from terminating the process. The repair entered main through #214. Separate #215 closed as superseded, and issue #210 also closed.
• Quota/logger metrics: read the effective quota field, make AddSystemTarget idempotent and serialize logger initialization/console-target publication, avoiding duplicate collectors after log subscriptions (#106, #150, #132, #151).

Dependencies, delivery and maintenance

• Upgrade amqp091-go 1.10.0 to 1.14.0, including bounded malicious-frame allocation; SILO reachability requires an AMQP notification target (#176, #177).
• JWX 3.3.0 escapes custom JSON field names; strfmt 0.27.2 repairs Go 1.27 hostname validation; LZ4 4.1.30 fixes reader, partial-read and concurrency behavior, with Snowball/S3 Select integration regressions.
• Cumulative upstream SDK changes include configurable upload limits, streaming Content-Type signing, caller TLS trust for RDMA, consistent listing checksums/optional restore status, and the HTTP-200 CopyObject repair above. See the upstream adoption record. Console also updates React Router to 7.18.4 and retains js-yaml/smol-toml denial-of-service fixes with rebuilt embedded assets.
• Refresh Go x/* dependencies while retaining Go 1.27.1, the NetBSD go-systemd 22.6.0 replacement and tablewriter compatibility selection.
• Refresh container base digests and build static curl 8.22.0 from verified source on both Linux architectures. Pin published mcli 20260916 archives and SHA-256 values in the installer and image.
• Pin GoReleaser 2.18.1 and action v7.2.3 by full commit; dependency-only changes now trigger Test Release Pipeline. Include Helm Chart 7.0.3 in the tag with the new Server/client defaults; there is no separate chart publication.
• Fix conditional PUT and tag-replication test-fixture races, restore valid integration credentials, and add CPU/tag/multipart/S3 Select race coverage.
• Maintain rebrand guards, AGPL-3.0-or-later/DCO/no-CLA contribution rules and human contribution records; refresh README repository cards daily.
• Consolidate formal product, upgrade, security and design documentation on this site. Retain repository entry points and necessary compatibility/testing documents; move temporary investigations out of public source and retain historical evidence through immutable links.

September 4 Helm image-tag correction, mcli archive pinning and recovery container publication completed the previous release’s delivery.

Withdrawn experiment

GET-frequency-based cross-pool ILM tiering #60 was merged during this cycle and removed by #188. It never shipped in Server 20260903 and is not a feature of this release. The tracker, mover, scanner hooks, dedicated configuration/XML actions and metrics are removed. Ten old ILM keys are accepted but ignored; v8/v9 usage caches are readable and v8 is written without retired fields.

Intermediate development deployments should remove access-only rules and retain ordinary actions in mixed rules. Ordinary expiry, remote tiers, rebalance and decommission remain; independent multi-pool lock, conditional-delete, write-coordination and shared-tier protections remain. See migration.

Upgrade and recovery requirements

1. Freeze final identities. Verify Server, Console, mcli, packages, images and Chart separately. Official image names are docker.io/pgsty/silo, docker.io/pgsty/mc and docker.io/pgsty/silo-console.
2. Migrate password denies and compare original policies. Preserve CreateUser and ChangeMyPassword in the same Deny when the old combined restriction must remain. Recover previously lost clauses from original sources.
3. Use coordinated maintenance. Pause IAM writes and isolate unknown offline sites. Upgrade every participating node/site, including nodes sharing IAM without site replication. Mixed old/new access to one IAM backend and rolling downgrade are unsupported.
4. Save complete recovery points. Back up IAM storage and required encryption material; mcli admin cluster iam export omits deletion history. Stop relevant processes before restoration so cached peer acknowledgements are not reused.
5. Verify every endpoint. Old revoked credentials must fail; new users, service accounts and newly issued STS credentials must work at every node. Check signed PUT/GET, bytes, versions, tags, retention and replication convergence before reopening traffic.
6. Reconcile revocations after rollback. An old snapshot loses later revocations. Reconcile each restored site and test every endpoint; use differently named replacement identities/reissued credentials when needed. Pre-restore STS continuity is not promised. Do not delete tombstones online or convert only live records to force an old binary to start.
7. Enable optional behaviors independently. Metadata tombstone export requires all participants upgraded. Strict multipart additionally requires all writers updated, legacy uploads drained, preflight and capacity validation. Ordinary upgrades may keep default legacy mode.
8. Handle development-build remnants. If an intermediate build persisted api multipart_listing, back up configuration and use mcli admin config reset ALIAS api multipart_listing to remove only that key, retaining other settings. Do not reset the entire subsystem or replay history containing the key. Follow the separate access-tiering retirement guide if that experiment was used.
9. Check TLS-inspecting devices on outbound paths. Handshake contents changed with the Go 1.27 toolchain in 20260903 and again here. An SSL-inspection NGFW, SASE gateway or IDS/IPS — or a JA3/JA4 client-fingerprint allow-list — can reset identity provider, webhook, remote tier or replication connections with connection reset by peer while curl from the same container succeeds. After upgrading, verify OIDC discovery and JWKS, audit and notification targets, remote tiers and replication endpoints. Remedies and their trade-offs: pinned TLS parameters and handshake compatibility.
10. Audit historical data separately. Inventory unreadable SSE-C, wrong part sizes, tags/locks, aws-chunked pollution, past erroneous overwrites and pending purges. Validate approved repairs on copies.

Runbooks: IAM upgrade/recovery, historical replica audit, password migration and multipart contract. While object and erasure layouts are unchanged, the new persistent IAM state prevents rolling downgrade to an older Server binary.

Known limitations and remaining work

Validation and release status

Released source 2a4d51406b7e passed Go CI and the Test Release Pipeline. The Release build and Finalize completed. The GitHub release provides 36 assets, including six-platform archives, Linux packages, SBOMs, checksums and attestations.

Console v2.4.1, mcli 20260916 and pkg v3.14.1 have independent published releases. At the 2026-09-17 recheck, anonymous token requests for standalone docker.io/pgsty/silo-console returned HTTP 401, so public pulls are not confirmed. Use Console’s GitHub binaries or packages. This standalone image limitation does not affect the source selected for Server embedding.

Issue index and acknowledgements

Fixed or completed within the described scopes: conditions #10/#133/#144/#199; federation #99/#100/#158/#165–#171; bucket metadata #77/#105/#112; encryption/attributes #107/#109–#115/#117–#120; embedded Console #108/#147/#148; replication recovery #136/#137/#139/#141/#152/#153/#185; runtime/metrics #106/#116/#150/#154/#176/#183/#210. The pool-migration tag repair is recorded as a direct main commit; #79 remains partially implemented and open. The sections above link the individual records and limits.

Thanks to reporters, patch authors and reviewers, particularly @mrjavadseydi (quota, multipart and tiering exploration), @nikitapogromsky (logger idempotency), @Aeirx (federated legal hold), @magicxor (early conditional DELETE proposal), @julienlau (purge/MRF), @chodorenko (replica encoding), @orenyomtov (signed headers), @jiri-pejchal (Console sharing), @AEGEGE (HTTP report), @aschyolkin (CPU race), and @vampywiz17, @kh0mka and other reproduction/feedback contributors.

Original PRs #12, #125, #155, #184, #187 and #195 were superseded by later implementations. See the full contribution record.

Previous release · Release source diff · Component matrix

2.12 - mcli 20260916 Released

Release: RELEASE.2026-09-16T00-00-00Z · Package: 20260916000000.0.0 · Source: e952aa78f10a.

Changes since 20260913

• Adopt silo-pkg v3.14.1, upstream minio-go v7.3.1-0.20260915093545-32e1f32cb176, and JWX v3.3.0. CopyObject retries and propagates S3 errors embedded in HTTP 200 responses, so a failed copy cannot authorize mv to delete its source. JWX correctly escapes JSON field names.
• Report mirror permission failures, including unreadable sources, rejected writes and failed local destination removals. Later objects continue; a finite mirror with failures exits 1. These per-object permission errors do not require --skip-errors and do not restart an entire watch scan.
• Preserve the existing cancellation/retry path for listing and watcher failures. Persistent listing permission denial can still cause repeated scans; this release does not redesign that retry policy.
• Suppress normal final success statistics after a failed mirror. Explicit --summary retains statistics: JSON uses status: failure; text error diagnostics remain on stderr. Transfers completed within one clock tick no longer produce infinite JSON speeds.
• Return failure for legalhold set/clear errors, partial recursive retention failures, and moves whose source deletion fails. mv waits for deletion results; successful copies are not rolled back. Retention reports each failed object once instead of duplicate or misleading diagnostics.
• Reject empty retention durations and invalid find --regex expressions with normal CLI errors instead of panics.

Automation and upgrade notes

Affected failure paths that returned 0 now return 1. Check final exit status and error records. For mv, a deletion failure may leave both the source and the successfully copied destination; inspect both before retrying.

Configuration format, aliases, MC_* variables, commands and package naming remain unchanged. The password-policy split introduced by pkg v3.14.0 is unchanged in v3.14.1. See the component matrix and password-policy migration.

SILO is the maintained administrative integration target. Compatibility with unmodified upstream MinIO and other S3 services remains best effort.

Delivery and validation

The release contains 19 assets: six Linux/macOS/Windows archives for amd64/arm64, six Linux RPM/DEB/APK packages, one archive checksum manifest and six package checksum sidecars. Archives, the manifest and DEB/APK packages have verified Sigstore build attestations bound to this signed tag and source commit. RPMs carry the PGSTY GPG signature (9592A7BC7A682E7333376E09E7935D8DB9BD8B20).

The final release commit passed Go tests on Linux, macOS and Windows with the race detector, Linux 386 tests, cross-compilation, vulnerability scanning and the release packaging pipeline. Pre-release acceptance also exercised both the published SILO 20260903 and fixed Server source 3c26a8b0b5bd, Object Lock and permission failures, CopyObject error injection, and both-architecture RPM/DEB/APK installation and upgrades. No reachable or imported-package vulnerability was found; an unused OpenPGP module-only advisory remains.

CI: VulnCheck · Test Release Pipeline · Crosscompile · Go · Release · Docker

The docker.io/pgsty/mc release and latest tags resolve to the verified Linux amd64/arm64 manifest:

sha256:cfc83108c3abb371f8fb84d99c1fdc88f8c237e022409b0081fb7c0a3be634dd

Download and installation · Client compatibility · Changes since 20260913.

The HTTP-200 CopyObject repair applies when mcli selects a single CopyObject: objects smaller than 64 MiB or explicit --disable-multipart. Larger copies use ComposeObject.

See pkg 3.14.1 for the precise JWX/GHSA-4cf7-xm37-g63h scope. A failed --json mirror without --summary emits no trailing statistics record; --skip-errors does not turn recorded failures back into exit 0. Some retention JSON failure records carry status: failure with an error object serialized as {}; consumers must not require a human-readable message.

2.13 - mcli 20260913 Released

Release: RELEASE.2026-09-13T00-00-00Z · Package: 20260913000000.0.0 · Source: 4f609a4d.

Changes since 20260903

• Preserve historical destination versions under mirror --remove --watch.
• Keep service-restart dry runs from executing a restart and make noninteractive behavior explicit.
• Return failure for transfer and S3 Select errors, honor explicit checksums on empty uploads, and retain pipe JSON output when quiet mode is enabled.
• Accept on/off boolean environment values and repair CLI/JSON behavior across supported platforms.
• Adopt pkg v3.14.0 and upstream SDK v7.3.1-0.20260910142817-60bd07042d49, refresh Go x/* and UBI dependencies, and keep Go 1.27.1. NetBSD retains the go-systemd v22.6.0 portability pin.

The package retains the policy Deny/NotResource and bounded wildcard repairs from pkg v3.13.3. Correctly preserved denies may now reject requests that relied on lost clauses. Recover already-lost clauses from the original policy source.

The new pkg also changes password capabilities. Read the password-policy migration before a coordinated Server upgrade. The matching password UI shipped in Console v2.4.1; see the component matrix for the coordinated upgrade.

Delivery and validation

The immutable release contains 19 assets: six archives for Linux, macOS and Windows on amd64/arm64, RPM/DEB/APK packages for both Linux architectures, checksums and package checksum sidecars. Archives and the checksum manifest have verified build attestations; RPMs carry the PGSTY GPG signature. Native macOS arm64 version and Go build metadata were checked against the released pins.

The release and latest tags of docker.io/pgsty/mc resolve to the same verified amd64/arm64 manifest:

sha256:aa5cc1401b3e1ab482d215d5717e9e69b4f14970a3656f330ed20a549fe19020

Container publication completed; both architecture images were pulled and their version output checked. Go, cross-compilation, vulnerability and Test Release gates passed before tagging. No reachable or imported vulnerable package was reported; unused OpenPGP retains module-only GO-2026-5932. Compatibility with upstream MinIO and other S3 endpoints is best effort; SILO is the maintained administrative integration target.

Download and installation · Compatibility notes · Complete source diff.

pipe streams nonempty stdin until EOF; empty input uses a regular zero-byte PUT instead of unknown-size multipart. Explicit checksum options reach the upload path. Quiet/non-TTY execution keeps progress disabled while retaining JSON results for both empty and non-empty inputs.

2.14 - silo-pkg 3.14.0 Released

v3.14.0 was published on 2026-09-13 from commit 827f8109 under the module path github.com/pgsty/silo-pkg/v3.

Password-policy migration

This release updates authorization semantics for self-service password changes:

• Policy.IsAllowedActions now allows admin:ChangeMyPassword by default unless explicitly denied, while admin:CreateUser still requires an explicit Allow. On matching Server and Console builds, denying admin:CreateUser alone no longer blocks a caller from changing their own password; denying admin:ChangeMyPassword does.
• The built-in readonly policy drops its previous admin:CreateUser Deny rule (so an explicit admin:CreateUser Allow granted by another attached policy can now take effect). The new consolereadonly policy adds bucket listing and uses the same permission split. Neither built-in policy grants user-management permissions on its own.
• Existing custom policies and user-level policy overrides stored in the cluster are not rewritten automatically.

To keep the previous restriction that blocks both user administration and self-service password changes, include both admin:CreateUser and admin:ChangeMyPassword in the same Deny statement (preserving its original resource scope and conditions) before upgrading and throughout your rollback window—older Server builds do not enforce a standalone admin:ChangeMyPassword deny on this endpoint. See the full password-permission migration guide.

September 16 follow-up: Console v2.4.1 ships the matching password UI alongside silo-pkg v3.14.1 and mcli 20260916. See the component version matrix for coordinated upgrade requirements.

Dependencies and verification

• Upstream minio-go update: Pinned to v7.3.1-0.20260910142817-60bd07042d49, bringing configurable upload size limits, streaming Content-Type signing, caller TLS trust propagation for RDMA, consistent listing checksums, and optional archive-restore status parsing fixes.
• Toolchain and dependency refresh: Refreshed golang.org/x/* modules while keeping the Go 1.26 minimum requirement, Go 1.27.1 build toolchain, and existing exported Go signatures unchanged. The go-systemd v22.6.0 replacement is retained for NetBSD cross-compilation compatibility.
• Testing and vulnerability scanning: Passed full -race test suites on Go 1.26.8 and 1.27.1, lint checks, LDAP configuration validation, and Go module proxy / checksum database resolution. Scanning with govulncheck 1.8.0 found no imported vulnerable packages (only the module-level GO-2026-5932 entry for unused OpenPGP subpackages remains).

This release retains the Deny/NotResource policy serialization fix and bounded wildcard matcher from v3.13.3 (policies that already lost statements under earlier versions must still be restored from their original source). The github.com/pgsty/silo-pkg/v3 module-path migration introduced in v3.13.0 is complete across all four maintained components.

Source changes since v3.13.3 · Upstream adoption record

2.15 - SILO Console 2.4.0 Released

v2.4.0 was published on 2026-09-08 from c103d08e.

Released behavior

• Object-browser directories load 100 entries per page by default, with choices of 50, 100, 250, 500 and 1000. Each page uses one S3 continuation-token request. Sorting, filtering and selection apply to the displayed page, not a complete directory scan; there is no unbounded “all” mode.
• Version deletion stays bound to the selected object and directory deletion to its prefix. Lifecycle edits preserve independent actions and unexposed settings; replication rule deletion is saved consistently.
• Transient network failures preserve sessions. Empty versioning state, malformed sidebar preferences and stale dropdown selections are handled.
• Embedded Console restores loopback proxy behavior when Server explicitly enables the policy; standalone trust defaults remain unchanged.
• Dependencies include pkg v3.13.3, MC source v0.0.0-20260908140805-c8aa5d25a63a, and upstream SDK 0e78d3f18efe. This release consumed MC as source and did not itself publish a new mcli tag.

Correctly preserved Deny/NotResource clauses may reject requests that relied on old deduplication defects. Restore already-lost clauses from the original policy source. Embedders must copy the MC replacement from the tagged README.

Later release

Console v2.4.1 adds restricted shared downloads, the password-permission split, streaming multi-object ZIPs, browser recovery and verifiable release artifacts. It selects pkg v3.14.1 and mcli 20260916. v2.4.0 uses the earlier browser-memory ZIP path. Read the password migration before upgrading.

The exact v2.4.0 source passed the complete Console CI matrix. See the tagged changelog, object-browser guide, and release assets.

2.16 - Silo Console 2.2.0 Release Notes

Published: 2026-08-26 · Version: v2.2.0 (7dc4258a6) · Repository: pgsty/silo-console

SILO Console 2.2.0 adds a bounded text preview for logs and structured text, tightens download error handling so truncated archives cannot pass as complete, fixes table-action permission gating, splits user status updates from group membership edits, and validates database notification DSNs and IAM policy documents before writing them to the server.

Underneath, the dependency stack moves to Go 1.27.0 and onto the maintained SILO packages: pgsty/silo-pkg 3.12.1 replaces upstream minio/pkg, pgsty/mc replaces upstream mc as a library, minio-go moves to 7.3.0, and the etcd client line moves to 3.7.1, closing CVE-2026-73500.

The final change set since v2.1.1 spans 33 commits touching 176 source files (+8,794/−2,057 lines, excluding regenerated embedded frontend assets).

Why 2.2.0 instead of 2.1.2: this release switches the shared policy/certificate package provider, crosses an etcd client minor version boundary, splits a REST route, and changes folder-download failure semantics.

Text Preview for Logs and Structured Text

The object browser can now preview .log, .txt, .json, and .xml objects as literal text. The implementation is deliberately paranoid, because “render arbitrary bucket content in the admin UI” is an XSS invitation:

• Bounded by construction. The request carries Range: bytes=0-1048576; the response is streamed into a fixed buffer with a hard cap, and Content-Range/Content-Length are strictly validated against what was actually read. An object over 1 MiB reports too large — it is never partially rendered as if complete.
• Text or nothing. The bytes must decode as strict UTF-8 (TextDecoder with fatal: true) and must not contain NUL; anything else reports not previewable instead of rendering mojibake or binary junk. Eligibility is an exact allowlist — the four extensions plus the precise MIME types text/plain, application/json, application/xml, text/xml — and .html/.htm/.xhtml are explicitly excluded even when their metadata claims text/plain.
• No active document. Content renders into a single DOM text node — never innerHTML, never an iframe, never a JSON-to-HTML transform. A regression suite feeds it HTML, SVG, and XML payloads and asserts they stay inert text.
• Race-proof. Switching quickly between objects invalidates in-flight previews by generation, so a slow response for the previous object cannot paint over the current one. Cancellation and retry are first-class states.
• Anonymous-friendly. Public/anonymous object pages get the same preview through the anonymous request path, without triggering any credentialed API call.

Alongside the new preview type, the existing preview plumbing was corrected: empty objects preview as empty instead of erroring, appended logs re-preview at their new length instead of the stale listed size, and metadata races when flipping between objects are gone. The preview and share dialogs now receive the object’s real size (92e8f4e65).

Download Integrity and Progress

The download pipeline — progress reporting, single objects, folders, archives, and byte ranges — enforces strict completion and error reporting.

Indeterminate progress when size is unknown

A missing, invalid, or contradictory total no longer becomes a fabricated percentage: the progress indicator stays indeterminate until the real total is known. Zero-byte objects are normalized deliberately instead of falling into the unknown-total path, and abort/cancel are terminal states — a late progress event cannot resurrect a cancelled download. Download requests settle exactly once, JSON error blobs are parsed safely, and generated object URLs are revoked.

Streaming folder downloads

Single-folder downloads now use the browser’s native streaming download path instead of accumulating the entire ZIP in JavaScript memory — a multi-GB folder no longer risks tab death. One consequence of the handoff model: the console’s transfer manager reports the folder download complete once it hands the stream to the browser (a toast says so), and the browser’s own download UI takes over from there — cancelling in the console after handoff does not stop the browser-side transfer. Multi-selection downloads still ride the existing POST response and therefore remain an in-memory Blob; changing that requires a separate API decision and is out of scope here.

ZIP integrity — a deliberate behavior change

Byte ranges and status codes

• Malformed or unsatisfiable non-empty Range headers now return 416 with Content-Range: bytes */N instead of a 500. Range parsing is stricter than Go’s lenient default: signs, embedded whitespace, bytes=-0, and empty range elements are rejected.
• A range request against a zero-byte object returns an empty 200 instead of a 500 — this was the empty-object preview bug.
• Failures from the lazy object Stat now surface the real S3 status (403, 404, …) instead of a blanket 500.
• 206 responses now set Content-Length before the header flush, so partial responses carry correct framing.
• Object sizes are now always serialized — REST and WebSocket listings report "size": 0 for zero-byte objects instead of omitting the field, and the UI displays 0 B. This is the ground truth the honest-progress work stands on.

Version history

S3’s valid null version ID stays visible instead of being dropped, version counting filters prefix matches to the exact object, and history is retained after bucket versioning is suspended or disabled.

Permission Gates That Actually Gate

Row actions were never disabled

Every screen with a data table passed its permission predicate through a prop name (disableButtonFunction) that the table component no longer reads — so view/edit/delete buttons rendered enabled regardless of permission, on every one of the 10 affected screens (Users, Groups, Policies, IDP, webhook settings, bucket access/replication/lifecycle panels). The predicates are now wired to the prop the component actually honors, and a source-guard test fails the build if the dead prop name ever reappears. Server-side authorization was never affected — the buttons produced errors when clicked — but the UI now communicates permissions instead of lying about them.

Independent service-account capabilities

Access-key management previously keyed several UI decisions off one combined permission check. 2.2.0 derives four independent capabilities — List, Create, Update, Remove — in one module and applies them consistently across the self-service Account screen and the admin user-details screen:

• the service-accounts tab shows when you can list, the create button when you can create, row selection and bulk delete only when you can remove, and the edit pencil only when you can update;
• View is now genuinely read-only: all fields disabled, no submit path, Enter is inert — previously “view” opened the editable dialog;
• the session’s advertised Create Access Key capability is computed correctly for request-scoped policies: a Deny conditioned on svc:DurationSeconds (an expiry restriction that can only be evaluated once a concrete request exists) keeps the capability visible — including with wildcard admin actions — while unconditional or login-time denies now properly hide it. The server remains the final authority at request time. The previous code kept the capability visible for any conditional deny, which over-advertised it.
• an OIDC create/list/get/delete integration regression now runs through the UI’s explicit-credential endpoint, including the expected self-update denial.

Validate IAM policies before writes

Named-policy and service-account policy writes now reject malformed documents and bare S3 resource ARNs with a client error before making an Admin API request. Historical policy reads stay permissive for compatibility, but an incompatible stored policy must be corrected before it can be saved again. The strict parser and resource checks live in the console’s write path instead of importing fork-only policy APIs, preserving the advertised upstream minio/pkg v3.6.1 source-build floor.

Anonymous pages behave anonymously

Anonymous object-browser pages no longer issue protected Object Lock/retention requests that could only produce Access Denied noise, and they gained the language (文/A) and dark-mode controls.

User Status and Groups Are Separate Operations

Toggling a user’s enabled/disabled status and editing their group membership were one combined PUT /user/{name} call that required both payloads and — through the combined permission gate — demanded admin:EnableUser merely to edit groups. 2.2.0 splits them:

• PUT /user/{name}/status (new) changes only the status, validates the value against enabled|disabled, and rejects the signed-in user’s attempt to enable/disable themselves. Failed toggles no longer leave the switch out of sync — the UI reflects the server’s answer, not an optimistic flip.
• PUT /user/{name}/groups (existing) is now the only thing group editing calls, and no longer requires admin:EnableUser.
• PUT /user/{name} survives unchanged on the wire as a deprecated compatibility endpoint for existing API consumers; an unknown status there is now a 400 instead of a 500.

See Compatibility for the API-contract details, including a caveat for regenerated Swagger clients.

Database Notification Forms That Emit What They Mean

The PostgreSQL and MySQL event-destination forms were rewritten around a shared DSN parser/serializer:

• Structured fields and the raw connection string are one state: the raw string stays authoritative until a structured field is edited, at which point a canonical DSN is rebuilt — libpq keyword/value quoting for PostgreSQL, IPv6-bracket-aware go-sql-driver format for MySQL. Mode switches no longer mangle manually entered strings.
• Generated previews mask credentials; the mask can never reach the API payload (the payload always uses the raw connection value).
• Saving requires both a connection string and a table, and cleared values actually propagate.
• The server now rejects DSNs its own configuration grammar would corrupt — embedded newlines, values that would parse as sibling config keys (table=… inside a password), unbalanced quoting — with a 400 before anything is stored, and without echoing the submitted secret back.
• Generic password and token fields across notification targets (Kafka, Redis, MQTT, NATS, webhooks) render as password inputs, including environment-overridden values.

Accurate restart-required status

Configuration add, update, delete, and reset now honor the server’s actual restart-required answer instead of hardcoding “restart needed” (or worse, dropping it). The pending-restart flag is monotonic: once any operation requires a restart, later operations that don’t cannot clear it — only an actual service restart does.

Upload advisory

Browser uploads larger than 5 GiB get a non-blocking warning: the console uploads as one non-resumable request, and mcli with multipart upload is the right tool at that size.

Sessions, Metrics Auth, and i18n Hardening

• Sessions fail fast. An anonymous/empty session gets an immediate 401 instead of hanging on an empty-credential admin request. The console accepts the canonical 401 and the legacy 403 invalid-session responses, and expired-session redirects are subpath-aware — a console served under /console/ redirects within its base path.
• Prometheus Basic auth works everywhere. The health check and the root-fallback probe now send Basic credentials (previously Bearer-only, so a Basic-auth Prometheus disabled every dashboard widget), Bearer tokens keep precedence, and every response body is drained so keep-alive connections are actually reused.
• Placeholder substitution is escape-proof by construction. Translated placeholder filling uses a one-pass literal formatter: values containing $&, $1, $`, backticks, or braces stay literal, repeated placeholders all fill, and an AST source-guard test bans the unsafe String.replace pattern from ever returning.

Toolchain and Dependencies

Go 1.27 baseline

The SILO forks

require github.com/minio/pkg/v3 v3.6.1

replace github.com/minio/pkg/v3 => github.com/pgsty/silo-pkg/v3 v3.12.1
replace github.com/minio/mc => github.com/pgsty/mc v0.0.0-20260806055018-b0021fd01ccb

• silo-pkg 3.12.1 is the release dependency. pgsty/silo-pkg v3.12.1 was published on 2026-08-25 and the console pins it directly. It builds on the 3.12.0 release, which carries the policy resource-boundary hardening, condition-key lookup repair, LDAP and certificate-watcher fixes, and the Go 1.27 / etcd 3.7 baseline.
• The mc library moved to the pgsty/mc fork at a date-tagged pseudo-version. Import paths are unchanged.
• The require line stays on upstream v3.6.1 deliberately. Go ignores replace directives in dependency modules, so a downstream module that requires this console resolves upstream minio/pkg — and the SILO v3.12.1 tag does not exist upstream. Requiring a real upstream tag keeps the console resolvable downstream; the replace applies the fork for the console’s own builds. The final CI verifies the public source-build surface against upstream v3.6.1. This is compile compatibility: a downstream build without its own top-level replace gets upstream behavior, not the fork’s SILO-specific IAM semantics.
• go-systemd is pinned back to v22.6.0: v22.7.0 uses CLOCK_MONOTONIC on NetBSD, which doesn’t compile there; the pin holds until upstream ships the fix.

etcd 3.7.1 — client libraries only

All three etcd Go modules move together from 3.6.8 to 3.7.1, closing the TLS-listener denial of service GO-2026-6107 / CVE-2026-73500. etcd 3.7 removes legacy protobuf remnants and makes clientv3.New non-blocking — migrations that matter to consumers that construct clients or embed servers. The console does neither: its only etcd path is silo-pkg/quick operating on an already-created client with plain v3 Get/Put. This upgrades compiled client libraries only — it does not touch an operator’s etcd servers, cluster data, or deployment topology; a server upgrade to 3.7 still follows etcd’s own one-minor-at-a-time procedure.

Third-party maintenance stays conservative

The final release updates minio-go to v7.3.0 after a separate compatibility review, migrates its INI import path, and adds lifecycle-filter XML coverage. A console-side compatibility decoder accepts legacy AccountInfo tag payloads returned by older servers. Other accepted maintenance moves include jwx v2→v3 with httprc v3, go-openapi/swag/conv+typeutils 0.28.0, grpc-gateway 2.29.0, cheggaaa/pb 1.0.30, and go.yaml.in/yaml/v3 3.0.5. Larger unrelated go-openapi, pb/v3, compression, and test-library updates remain deferred.

On the frontend, the vulnerability workflow now covers pushes, manual runs, and development dependencies with immutable installs; vulnerable transitive resolutions were refreshed (fast-xml-parser 5.11, nanoid 3.3.18, @babel/core 7.29.7), and dead exports along with the unused http-status-codes dependency were removed. The fast-xml-parser 5.x transitive packages are development-only and are not bundled into the browser build.

Security Review

• govulncheck at the release tree: zero vulnerable symbols reached, zero vulnerable imported packages. The Swagger build tool scans clean separately.
• Closed by dependency moves: CVE-2026-73500 (etcd TLS listener DoS), CVE-2026-56864 / CVE-2026-56865 (x/mod verification).
• Still reported, still unreachable: the module-level GO-2026-5932 openpgp advisory — the console does not import x/crypto/openpgp, and no fixed release exists.
• The text preview was reviewed as an XSS surface (see above); its regression suite includes active-payload tests.
• The permission-gating fixes are UI-truthfulness fixes: server-side authorization was never bypassed in 2.1.1; the console simply displayed controls it shouldn’t have.

Compatibility

Nothing changes for deployment plumbing: no environment variable, configuration format, command, binary name, systemd unit, port, or embedded data layout changes. The release binary remains self-contained; Go 1.27.0 is a build-time requirement only.

HTTP API contract (console’s own REST API):

Behavior changes an operator may notice:

1. Folder/ZIP downloads over partially readable prefixes fail instead of silently omitting unreadable objects (details).
2. Range parsing is stricter than Go’s lenient default; degenerate range headers (bytes=-0, empty elements) now get 416 instead of best-effort handling.
3. Database notification configs that only worked by accident (DSNs the config grammar mangled on the way in) are now rejected up front with a 400.
4. The Create-Access-Key control is hidden for sessions whose policy unconditionally denies it (previously any conditional deny kept it visible).
5. A pending restart-required indicator persists until an actual restart, instead of being clearable by a later unrelated config change.
6. If a reverse proxy in front of the console compresses /api/v1/…/download responses, the text preview’s strict Content-Length verification will reject every preview as an error. The console itself only compresses static assets — leave API responses uncompressed at the proxy.

Known Limitations and Follow-up Items

Wiring the table disable prop exposed two pre-existing UI-guard defects where predicates compare a row object against a string:

• the “cannot delete the Default IDP configuration” row guard compares the row object against "Default" and therefore does not disable the button (IDPConfigurations.tsx);
• the “cannot delete an env-override webhook endpoint” row guard has the same object-vs-string mismatch (WebhookSettings.tsx).

In both cases the server still enforces the restriction when the action is submitted. Additionally, the PostgreSQL DSN parser populates structured fields only from canonical key=value syntax (non-standard libpq DSNs display empty structured fields and rebuild from those fields if edited), and TestCafe/Playwright suites cover UI gating while live-server deny paths are covered by the integration suites.

Verification

The release decision combines local release-preparation evidence with remote gates run against the exact tagged tree, 7dc4258a6:

Local release-preparation gates — go build ./..., go vet ./... (plus -tags testrunmain), gofmt, golangci-lint, go test -race ./..., go tool swagger validate, govulncheck, TypeScript tsc, Playwright, Prettier, knip, release-tag cross-compiles for linux/amd64 and linux/arm64, and go mod verify.

Embedded-assets determinism — the frontend was rebuilt from source through the full pipeline (yarn build + embed optimization) and the result compared against the committed web-app/build: byte-identical, zero dirty files. The nine commits after the earlier 19047161f candidate changed Go compatibility, workflows, and browser-test timing, but not product frontend source or embedded assets.

CI, exact final tree — Workflow run 32888892876 reported 32 successful jobs and one explicitly disabled React-test placeholder. It covered lint, semgrep, Go and API tests, five cross-compile targets, Swagger drift, latest-MinIO source builds, distributed integration, site replication, hermetic SSO, the complete TestCafe permissions matrix, subpath-nginx, Playwright, and coverage. Vulnerability Check 32888899120 passed both jobs on the same commit.

Release pipeline — goreleaser run 32916237254 passed both jobs against v2.2.0 and published the public GitHub release.

Downstream contract — in a scratch tree with every replace removed, go mod tidy + go build ./... succeed against upstream minio/pkg v3.6.1, proving the fork replacement never leaks fork-only symbols into the public module surface.

Test-infrastructure repairs shipped in this cycle (so the gates above actually gate): the Docker-backed integration/replication/SSO suites are back behind the testrunmain build tag (a bare go test ./... no longer tries to start containers); the SSO gate is hermetic — no sudo /etc/hosts edits, no ad-hoc pip installs, pinned SILO image, own port, real teardown; the integration gate asserts the new 416 range semantics and stopped binding its PostgreSQL fixture to a host port; the browser gates run off-Linux by publishing fixture ports; a stale pre-fork “MinIO administrator” selector was fixed; state-mutating TestCafe suites are serialized; Playwright CI installs the committed lockfile immutably.

Release Artifacts

The v2.2.0 GitHub release publishes:

1. six standalone binaries: Linux amd64/arm64/armv6, macOS amd64/arm64, and Windows amd64;
2. nine Linux packages: DEB, RPM, and APK for amd64, arm64, and armv6;
3. silo-console_2.2.0_checksums.txt, plus the SHA-256 digest GitHub records for every asset.

Related Commits

• 16960f7ab — fix: keep unknown downloads indeterminate
• 5968bb37d — chore(deps): align the SILO Go dependency stack
• 288ab1240 — fix: harden sessions, metrics, and translations
• ecf3bb492 — fix: harden object previews and downloads
• 902d9650d — chore: tighten dependency and test gates
• 194c70c7a — build: prepare SILO Console v2.2.0
• 927b44e26 — fix: harden database notification forms
• da2191be9 — fix: clarify console upload and secret limits
• 6141c2445 — build: refresh SILO Console v2.2.0 assets
• 097e76155 — chore(deps): bump the shared package fork to v3.12.0
• 99ca523d6 — fix: split user status updates out of the combined user route
• f4097992f — fix: honor the server restart result for configuration changes
• f1280032a — fix: restore permission-gated table row actions
• 24ce0af97 — fix: keep request-scoped access key conditions visible in the console
• 92e8f4e65 — fix: pass the object size into the preview and share dialogs
• 8f6fb3c78 — test: make the SSO gate hermetic and pin it to a SILO release
• 384a2cb95 — build: refresh SILO Console assets and record the changes
• a73cda376 — test: fix the integration gate’s stale range and host port
• cf5049c1d — test: make the browser gates runnable and fix a stale selector
• 6fa19d857 — fix: complete service account permission boundaries
• 7e57771a4 — build: refresh SILO Console assets
• 57cfe7aa0 — fix: restore downstream and browser release gates
• 19047161f — test: stabilize permissions browser gates
• e37dec873 — fix: validate IAM policies before writes
• 28505ed23 — chore: update minio-go to v7.3.0
• 16abb971e — ci: harden validation and release gates
• 2ddfcd036 — fix: accept legacy AccountInfo tag payloads
• 31332bca9 — fix: preserve policy source compatibility
• 3a8251086 — ci: allow permission tests to finish
• c159fff78 — ci: serialize shared-role permission tests
• 2e91cdf9a — test: wait for watch controls to become ready
• 7dc4258a6 — test: allow asynchronous UI controls to settle

Links:

• SILO Console source · v2.2.0 release
• silo-pkg 3.12.1 release · silo-pkg 3.12.0 release notes
• SILO website · Documentation

2.17 - SILO Console 2.5: Interface and Administration Updates

SILO Console v2.5.1 is now released (commit fff1618d9abb) and ships embedded inside SILO 20261026. This note summarizes the full 2.5 release series since v2.4.2, combining the v2.5.0 interface overhaul and the v2.5.1 patch fixes.

GitHub release · Downloads · Full commit comparison

Navigation, overview, and metrics

The 2.5 interface adopts neutral light and dark themes, system typography, consistent information density, Lucide icons, clear keyboard focus states, and prefers-reduced-motion support. A mobile drawer and tablet rail adapt navigation to narrow viewports while respecting saved user preferences; object details open in a focus-restoring bottom sheet on mobile, and dialogs and forms scale cleanly to smaller screens. English and Chinese localization, accessible controls, and license attributions remain built in.

Permission-aware navigation organizes Identity, Monitoring, Settings, and Tools around the active session’s grants, consolidates bucket access under a single Buckets entry with recent-bucket shortcuts, and preserves post-login redirect targets and existing object deep links (/browser redirects to /buckets, and bare bucket-management URLs open the Summary tab). Help continues to link directly to Documentation, Video guides, and Blog/RSS feeds.

The Overview dashboard displays node and drive health, raw physical capacity, active alerts, quick actions, and data freshness. Capacity panels report the exact figures returned by Server rather than estimating usable erasure-coded capacity, marking uncollected statistics as unknown. Metrics V3 panels under Monitoring distinguish missing Prometheus samples from true zero values and handle per-node cluster metric exports accurately. Note that while Server 20261026 returns a live bucket inventory, bucket and account usage totals remain scanner-derived.

Buckets, object browser, and tasks

• Bucket list: Supports sorting, name filtering, URL query-parameter persistence, table/card view toggling, large-list virtualization, and explicit unknown-usage badges. Stable row keys keep selection attached to the right bucket across sorts, and in-flight search updates are discarded on navigation.
• Fine-grained permission handling: Write-only users can enter the object workspace; wildcard bucket-root grants and prefix restrictions are preserved; and rejected actions (such as tag edits) surface the server’s error message directly (listing, read, and mutation permissions remain evaluated independently).
• Bounded previews and CLI hints: Adds bounded 1 MiB previews for plain text, Markdown, and CSV/TSV files alongside source views, sanitized HTML rendering, and explicit truncation notices. Supported configuration forms also display secret-redacted mcli command equivalents.
• Tasks center: Tracks uploads, downloads, native streaming ZIP downloads, bulk deletes, noncurrent-version cleanup, and object restores with bounded mutation concurrency and failed-item-only retries (canceling a task does not roll back already-completed writes; verify large object or streaming ZIP downloads on disk after browser transfer completes).
• Keyboard navigation and pagination: Adds arrow-key navigation, Shift-range selection, current-page Select All, a keyboard-shortcut reference dialog, and permission-aware context menus. Cursor pagination remains unchanged—sorting, filtering, and Select All operate on the current page.

Identity management and high-latency diagnostics

User detail pages display account status, direct policies, group-inherited policies, and Access Key counts; policy pages distinguish native built-in, overridden built-in, and custom policies while showing assignment counts and affected identities. Native built-in policies remain read-only until explicitly overridden, and modified built-in policies offer a one-click Reset. Failed reloads clear stale editor contents, language switches preserve unsaved drafts, and forms bind labels properly while masking remote secrets.

Note: Built-in policy Reset and live bucket inventory require Server 20261026. Upgrading standalone Console by itself does not update an older Server’s policy cache or replace its embedded frontend.

Across all six live diagnostic streams (Health, Trace, Logs, Watch, Speedtest, and Profile), Console now completes the WebSocket close handshake through the single existing reader goroutine with a shared five-second close budget that never cuts off active streams. This fixes the high-RTT health-report truncation and abnormal 1006 closures reported by Azat / @azataiot in #63 (wrapped timeouts still return close code 1008 without leaking internal details). Health-report downloads also reuse a single JSON decoder across the version probe and payload so buffered bytes are never dropped, reject truncated or canceled streams, and retain signed madmin v3 transport and retry behavior.

Fixes in 2.5.1

• Group status toggles (#67): Enabling or disabling a group now preserves its existing members, while an explicit members array continues to replace membership.
• OIDC groups and reverse-proxy cookies (#66): Preserves permissions for OIDC string-array group claims and sets Secure session cookies only when HTTPS or a trusted TLS proxy header is configured.
• Credential exports and streaming ZIP errors (#68): Preserves exact UTF-8 JSON bytes when exporting Access Keys, and propagates the S3 HTTP error status when a streaming ZIP download fails before writing its first response byte.
• Accessibility and focus restoration (#68): Restores keyboard focus across tables and dialogs, adds accessible names and progress-bar value attributes, and keeps the focused tab visible when resizing the viewport.
• Companion dependencies (#69): Updates to mcli 20261026, silo-pkg v3.15.2, and the upstream SDK fix accepting HTTP 204 when removing bucket replication.

Dependencies and delivery

Console 2.5.1 builds with Go 1.27.3, Node 24.22.1, Vite 8.3.5, GoReleaser 2.19.0, silo-pkg 3.15.2, mcli 20261026, and upstream minio-go 320af050c445, while keeping tablewriter v0.0.5, go-humanize v1.0.1, go-runewidth v0.0.29, and go-systemd v22.6.0 pinned for output and platform compatibility (see the shared dependency and security inventory).

The GitHub release provides platform binaries and archives, Linux packages, source tarballs, SHA-256 checksums, SPDX SBOMs, and Sigstore/GitHub provenance attestations. Windows archives now use .zip (Linux and macOS retain .tar.gz), and multi-architecture container images are published at docker.io/pgsty/silo-console:v2.5.1 (see the release contract for verification commands).

Frontend assets and embedded bundles build reproducibly in isolated workspaces. The supported administration target is pgsty/silo (with best-effort upstream MinIO compatibility), and all existing CONSOLE_* environment variables, API routes, service names, and Go module paths remain unchanged; see the Console compatibility guide for API and embedding details.

2.18 - silo-pkg 3.15: Go 1.27.3 and S3 SDK Fixes

silo-pkg v3.15.2 is now released (commit 0416eb1f4505) and is adopted directly across the SILO 20261026 stack as github.com/pgsty/silo-pkg/v3. This note summarizes the full 3.15 series (v3.15.0, v3.15.1, and v3.15.2) since v3.14.3.

3.15.0: Toolchain and shared dependencies

The module’s minimum Go version increases from 1.26 to 1.27.3, alongside updates to 13 direct dependencies: JWX 3.4.0, etcd api / client/pkg / client 3.7.3, gRPC 1.84.0, grpc-gateway 2.32.0, go-json 0.11.2, swag/conv 0.29.2, go-colorable 0.1.16, cpuid 2.4.1, fwd 1.2.1, and the two Google generated API/RPC modules pinned at ce908d29299b.

Downstream applications must rebuild with Go 1.27.3 to pick up the Go standard library’s certificate-verification fix. All public package APIs, IAM policy formats, authorization rules, and the v3.14.3 policy evaluation optimizations remain unchanged.

3.15.1: Upstream S3 SDK fixes

v3.15.1 advances upstream minio-go from v7.4.1 to ab93db7ba435, bringing in six fixes:

• Rejects truncated sequential and parallel streamed multipart uploads before transmitting an incomplete part.
• Preserves sequential read state after ReadAt hits EOF and rejects negative ReadAt offsets before fetching object metadata.
• Fixes read and Seek bounds after calling Object.Stat.
• Deduplicates batch-delete fallback errors so each failed entry is reported once.

3.15.2: Bucket replication removal

v3.15.2 advances upstream minio-go to v7.4.2-0.20261025165926-320af050c445 (a pinned pseudo-version, as upstream has not tagged v7.4.2). Removing bucket replication—including passing an empty configuration to SetBucketReplication—now accepts both HTTP 200 and HTTP 204 while continuing to surface AccessDenied and other real errors (see upstream comparison).

Compatibility and verification

Downstream applications that rely on established CLI formatting and NetBSD builds continue to pin go-humanize v1.0.1, go-runewidth v0.0.29, and go-systemd/v22 v22.6.0. Because Go does not inherit replace directives from dependencies, each consuming application declares its own module replacements.

v3.15.2 passed the full lint and -race test suites (including live LDAP integration), module verification, and all three CI workflows (Go, LDAP, and VulnCheck). HTTP fixtures verified that both replication-removal entry points accept 200/204 while preserving 403 errors, and earlier 3.15 regression suites covered JWT validation boundaries, local etcd auth/watch/lease persistence, and CLI formatting. Scanner finding GO-2026-5932 resides in deprecated OpenPGP packages that silo-pkg does not import (see the shared security inventory).

require github.com/pgsty/silo-pkg/v3 v3.15.2

silo-pkg is a source-only Go module adopted by rebuilding Server, Console, and mcli. The supported dependency graph is the coordinated PGSTY stack, with best-effort upstream MinIO/MC compatibility. GitHub release · Full commit comparison.

2.19 - Silo Console 2.1.0 Released

Published: 2026-08-06 · Version: v2.1.0 · Repository: pgsty/silo-console

SILO Console 2.1.0 is the first feature release after the independent 2.0.0. It delivers three main changes:

1. Bilingual interface — every console screen, help topic, and documentation link now renders in English or Chinese behind a toggle on every page, with zero new runtime dependencies;
2. Metrics V3 dashboard — the dashboard moves from MinIO Metrics V2 names onto V3, with explicit handling for the semantics V3 changed underneath it;
3. Edge-case correctness fixes — a select-all that matches what a bulk action will delete, placeholders that handle object names containing $&, timestamps with an explicit timezone, and empty metrics that display “no data” rather than a fabricated 0.

This is a minor release. No environment variable, module path, API contract, binary name, or data layout changes. Upgrading is a binary or image swap.

A Bilingual Console

The console is an administration surface for an object store, and a large share of its operators read Chinese first. 2.1.0 makes the interface bilingual without importing an i18n framework — the embedded delivery model means every kilobyte is paid for in the binary. This is issue #6, which proposed i18next; the dependency-free substitution is the one deliberate deviation from it.

How it works

The design constraint was: no new dependency, no build step, no extraction pipeline, and partial coverage must never break the page.

• English source strings are the dictionary keys. t("Create Bucket") looks up the Chinese entry; a missing key returns the English string unchanged. Coverage can therefore grow incrementally, and a typo degrades to English rather than to a raw key like console.bucket.create.
• Three dictionaries, one merge. zh.ts (165 chrome entries), zhHelp.ts (247 help-topic entries), and zhScreens.ts (1,373 screen entries) merge with chrome taking precedence — about 1,785 entries in total.
• The language preference mirrors dark mode: localStorage → systemSlice → setLanguage. There is no browser-locale detection; the default is English, and the choice is explicit.
• Central interception points rather than per-callsite edits: the page-header wrapper, confirm dialogs, help items, route definitions, and the dashboard’s panel renderer each translate on the way out. This is why 220 screen files could be localized without touching their business logic.
• Module split matters. i18n/lang.ts holds pure primitives (translate, localizeUrl) and imports no store — systemSlice depends on it, so importing the store back would form a cycle. The hooks (useT, useLanguage, useLocalizedLink) and interpolate() live in i18n/index.tsx.

The toggle is a stroke-drawn 文/A icon mounted in the page header on every page and reused on the login page.

What it covers

Login and SSO flows, navigation and the command palette, the dashboard and every metrics panel, buckets and the full object browser (uploads, previews, sharing, versioning, rewind), users/groups/policies/access keys, configuration and event destinations, IDP and KMS, logs, health reports, speedtest, profiling, inspect, trace, watch, and the license page.

Beyond visible strings:

• Documentation links localize. silo.pgsty.com links gain a /zh prefix in Chinese; the Pigsty site swaps domains (pigsty.io ↔ pigsty.cc). GitHub, MinIO, AWS, and YouTube links are left alone.
• The help blog feed is per-language, fetching /zh/blog/index.xml in Chinese, with an independent cache per language.
• The command palette stays searchable in both languages. Menu entries translate for display but keep their English originals as keywords, so “桶” and “buckets” both match.
• Chart legends translate only their static prefix. translateLegend preserves instance suffixes like [server:drive], and the data layer keeps raw legends so components that match on them for arithmetic (capacity summing) keep working.
• Timestamps are unified, not merely translated — see below.

What it costs

Roughly +61 KB on the embedded payload (2.79 MB → 2.85 MB, +2.2%), zero new dependencies, and the dictionaries land in their own lazily-loaded chunk. The English rendering path is byte-stable: with the default language, output is identical to 2.0.0.

What stays English

Backend error strings (182 of them) are produced by the Go server and are not translatable from the frontend. A handful of strings hardcoded inside the vendored mds component library — the collapsed-menu “Sign Out” tooltip, and the data table’s “Columns”, “Loading…”, and ON/OFF toggles — remain English; two of them (“Sign Out”, “Actions:”) are swapped via a scoped CSS rule, but the rest would require patching the vendor.

Metrics V3 Migration

The dashboard queried MinIO Metrics V2 names. SILO deployments scrape V3 (/minio/metrics/v3), so the dashboard depended on an endpoint the monitoring pipeline no longer collected. 2.1.0 rewrites all 26 widgets onto the V3 catalog — 31 queries over 29 distinct metric names — and drops three widgets (51/61/62) that no layout ever referenced. This is issue #7; the Info-page half is #8.

The decision is V3-only: no runtime fallback, no probing, no version-selection knob. SILO Console targets SILO deployments, where the server, the scrape pipeline, and the console ship together. The SILO server keeps serving V2 endpoints for external consumers; the console simply stopped using them. A fallback would have been actively harmful — a metrics store retaining 15 days of V2 series would let an or-fallback silently read stale data.

The semantics V3 changed

Three properties of V3 break a naive name-for-name rewrite, and each needed a deliberate answer:

1. Cluster groups are exported identically by every node. /cluster/* metrics carry no server label and are not leader-gated, so an N-node scrape yields N duplicate series. Queries aggregate with max()/min() — never sum(), which would multiply cluster totals by the node count.
2. Zero values are not exported at all. Any metric whose value is ≤ 0 is skipped. Offline drive counts, healing-drive counts, and erasure-set health simply vanish rather than reporting 0, which a stat card renders as an empty panel. Every affected query carries a companion guard so the panel reads a real 0.
3. There is no minio_heal_* namespace. The V2 heal activity signal was in-memory anyway — it reset on restart and bumped on any scan. It is replaced by two cards with defensible semantics: Erasure Health (baselined on write quorum) and Usage Data Age (how stale the scanner’s usage snapshot is).

Zero-state semantics

The migration distinguishes zero, no data, and not yet scanned across eight edge cases:

• Capacity free/used baselines on the always-present total, so a full cluster reads 0 free instead of vanishing.
• Online Drives is guarded against the all-offline case, where the zero-skip would erase the panel when all drives are down.
• Bucket and object counts guard on the usage group’s own freshness gauge, so a cluster that has not completed its first scan reads no data rather than a fabricated 0.
• Empty single-value results render as —, not 0.
• An empty size distribution no longer fabricates seven zero-height bins.
• Fractional rates stay visible (parseFloat axis domain, two-decimal CPU formatter) instead of collapsing to 0.
• Sub-second Usage Data Age clamps to “1 second” instead of rendering blank.

A regression suite (api/admin_info_metrics_test.go) now pins every widget query to the V3 catalog, asserts widget-ID uniqueness, and enforces the per-widget guard taxonomy: health and traffic widgets need a nodes-online companion, usage counts need the usage-group freshness companion, and capacity needs the total baseline. The full mapping is documented in docs/metrics-v3.md.

Also fixed

• Widget 17 queried sent_bytes twice and widget 11 queried syscall_read twice — both internode/syscall pairs were transposed into duplicates.
• Label-less matrices (the result of max() aggregation) serialize with no metric field at all, which crashed the frontend’s label extraction and produced a 0 B capacity donut and an empty usage-growth chart. Guarded.
• An unused per-widget Prometheus label-values prefetch stalled every widget request by up to a second. Deleted.
• The dashboard’s usage cards, chart controls, and dense Traffic/Resources panels were rebuilt on one grammar and now reflow through tablet widths.

Two server-side bugs were identified during this work and are tracked upstream rather than worked around here: minio_cluster_usage_buckets_since_last_update_seconds emits nanoseconds (the objects variant is correct), and V3 bucket-level sent/received traffic are transposed.

Correctness Fixes

Placeholders that survive real object names

String.prototype.replace interprets $&, $', $`, and $1 in the replacement value as directives. S3 keys legally contain $. So an object named report$&.csv did not render as itself — it re-injected the matched placeholder text into the output and corrupted the message. All 37 dictionary placeholder substitutions now pass the value through a function replacement, where no such interpretation happens. This bug existed in the original English UI and surfaced during the localization audit.

A select-all that matches bulk actions

The vendored data table renders a plain untranslatable “Select” header whenever onSelectAll is absent — which was the case on all seven selectable tables. Worse, the naive fix is wrong: a select-all that replaces the whole selection drops rows hidden by an active filter, so the header checkbox and a subsequent bulk action can target different sets. The implementation toggles only the currently visible rows and preserves filter-hidden selections, so the header state can no longer imply a different set than the action would touch.

Timestamps with a timezone

Bucket, object, version, rewind, and access-key timestamps rendered as a mix of verbose English forms and — in several places — a 12-hour clock without AM/PM, which is simply ambiguous. All of them now render as yyyy-MM-dd HH:mm[:ss] (ZZZZ) in both languages.

A translation runtime that survives live data

t() also receives runtime strings: user agents, RSS titles, object names. Two hardening changes followed:

• misses return unchanged, unconditionally — the implicit @context suffix stripping is gone, because it silently mutated live data that happened to contain @;
• dictionary lookups are guarded with hasOwnProperty, so a hostile input naming an inherited Object.prototype member (constructor, toString) cannot leak a function into the UI.

Interaction and accessibility

• An expired session opening a deep link bounced through /login and back, accumulating a redirect chain instead of landing on the form once (#1).
• Collapsed sidebar buttons carried no accessible name; screen readers announced them as unlabelled (#4). Access Key inputs now declare their autocomplete intent instead of letting password managers guess (#5).
• Mobile metrics and bucket panels scroll instead of clipping (#3).
• The speedtest control row wraps instead of overflowing its card, its duration accepts seconds or minutes, and its size defaults to MiB to match its own unit list.
• Sidebar bucket rows use a virtual row pitch matching the 44px item, so selected and hovered highlights no longer overlap.
• Unit chips render the selected unit’s label rather than its raw value.

No SUBNET, No Telemetry

Upstream removed Subnet, Registration, and Call Home; this fork inherited that state but still carried three traces. 2.1.0 removes them:

• the health websocket’s subnetResponse field never addressed a subnet — it is a sentinel meaning “the report was assembled” — and is now reportStatus: "ok";
• two help topics claimed the health report “uploads automatically to SUBNET” and that inspect output is “transmitted to SILO SUBNET”. Neither was true. They now describe what happens: the report is generated on the deployment and downloaded by the browser;
• the unreferenced CONSOLE_SUBNET_PROXY constant is deleted.

For the record, 2.1.0’s outbound network posture is unchanged and remains: no analytics, no telemetry, no beacons, no external scripts or fonts. silo-console update is still disabled. The release catalog is contacted only if SILO_RELEASE_SERVICE_HOST (or RELEASE_SERVICE_HOST) is explicitly set — there is no default. The only automatic outbound request the browser makes is the help panel’s blog feed, and only after a user opens the Blog tab.

Upgrade Guide

There is nothing to migrate. No environment variable, module path, protocol field, systemd unit, binary name, or data layout changes between 2.0.0 and 2.1.0.

install -m 0755 silo-console-linux-amd64 /usr/local/bin/silo-console

Two things are worth knowing:

• The dashboard now requires Metrics V3. If your Prometheus scrapes only the V2 endpoints, dashboard panels will read no-data. Point the scrape at /minio/metrics/v3; Pigsty-managed deployments already do.
• The language default is English, chosen per browser and stored in localStorage. There is no server-side default and no browser-locale detection, so no existing deployment changes appearance on upgrade.

Verification Scope

Before tagging, the following verification checks ran against the final tree: go build, go vet, golangci-lint (0 issues), the Go unit suite across all packages, gofmt, TypeScript type checking, the frontend production build, Prettier across all sources, dictionary duplicate-key checks, and a debug-leftover scan of the complete diff.

The embedded payload was rebuilt twice from a clean directory and confirmed byte-identical for the release pipeline’s zero-diff gate. Metrics V3 queries were validated against a live metrics store with real cluster data.

Known Limitations

• The SSO end-to-end suite requires an external OpenLDAP/Dex/MinIO topology and was not run in that environment this cycle; the OIDC code paths are covered by unit tests.
• Backend error strings and several vendored mds component strings remain English (see What stays English).
• Chinese translation covers the console’s own surfaces; help-topic bodies are translated, but the documentation pages they link to follow the docs site’s own language coverage.
• Two server-side V3 metric bugs (nanosecond bucket-usage age, transposed bucket traffic) are tracked upstream and are not worked around in the console.
• Automatic self-update remains disabled; upgrades are explicit.

Issues Closed

2.1.0 closes every issue filed against 2.0.0. Each carries a comment on the tracker describing the fix, the commits, and the coverage added.

Three acceptance criteria are recorded as unmet rather than quietly ticked: web-app has no unit-test runner, so the i18n test suite (#6) and the focused constructLabelNames test (#2) would require introducing test tooling first, and #6’s contributor documentation for adding translation keys is not yet written.

Related Commits and Links

The complete v2.1.0 change set consists of 20 logical commits. The v2.1.0 tag additionally carries three later documentation commits that rewrote the repository README; they change no shipped behavior.

• 8764f5d — fix(web): stop recursive login redirects
• 437c56c — fix(ui): make the dashboard and bucket list usable on narrow screens
• 85fc0c6 — fix(a11y): name collapsed sidebar controls and credential fields
• e3fed07 — fix(metrics): rebuild dashboard cards, chart controls, and layout
• fa11576 — feat(login): polish controls and legal attribution
• 9fc17c1 — feat(i18n): add hand-rolled EN/ZH core, dictionaries, and language toggle
• 622c02e — feat(i18n): localize login, navigation, and the help system
• 6a03719 — feat(i18n): localize dashboard and metrics screens
• 14b1c2d — feat(i18n): localize bucket and object browser screens
• 0298062 — feat(i18n): localize identity, configuration, and event destinations
• 41094f6 — feat(i18n): localize observability, admin tools, and shared components
• e964992 — feat(metrics): migrate the dashboard to MinIO Metrics V3
• 0b2251f — fix(i18n): harden the translation runtime for live data and chart legends
• 9b60148 — fix(console): unify timestamps on a timezone-carrying standard format
• bf110ae — fix(console): give selectable tables a visible-rows select-all
• 5fc8f22 — fix(i18n): escape-proof all placeholder substitutions
• fef8fab — fix(console): polish speedtest, sidebar, and help chrome
• c4911e8 — chore(console): drop SUBNET remnants from health reporting
• 1d631c4 — docs: record the SILO Console v2.1.0 changelog
• 912d847 — build: regenerate optimized embedded web assets

Links:

• SILO Console source · Releases
• SILO website · Documentation
• Licensing · Attribution · Trademark

2.20 - Silo Console 2.0.0 Released

Published: 2026-08-04 · Version: v2.0.0 · Repository: pgsty/silo-console

SILO Console 2.0.0 is the first major release of this object-storage administration console as an independent project. Continuing from the georgmangold/console v1.9.1 maintenance line, it accomplishes three things:

1. An independent identity — product name, visual system, documentation entry points, source attribution, and the release pipeline all move into the SILO project, while the Go module path, environment variables, and other compatibility contracts are deliberately retained;
2. A redesigned interface — the login page, theme system, dashboard, and console details are reworked under one design language, backed by a regenerated brand icon set;
3. Hardened engineering — the embedded frontend payload shrinks from roughly 10MB to 3.5MB, known dependency vulnerabilities drop to zero, and a batch of inherited defects — including a runtime data race — is fixed.

Why 2.0.0

This console originated as MinIO Console and was carried forward by the Alevsk/console and georgmangold/console community maintenance lines. SILO Console continues from there, maintained by the Pigsty community as the browser-based administration interface for SILO.

The version jumps from v1.9.1 to v2.0.0 because these public contracts change together:

• the product is now uniformly SILO Console, with the primary repository at pgsty/silo-console;
• the release binary changes from console to silo-console;
• release assets, checksums, package metadata, CLI descriptions, and project links all switch to SILO;
• in-product identity, help entry points, copyright attribution, source offers, and trademark notices are re-established.

The migration strategy is “clear external identity, restrained internal compatibility”: operators must take notice, but the underlying compatibility interfaces are not mechanically renamed.

Naming and Delivery Contracts

For container deployments, use pgsty/silo-console on Docker Hub. See the Console v2.4.1 release notes for the current version and pull command.

CLI authorship, usage text, and project descriptions now identify Pigsty and SILO Console. DEB/RPM/APK vendor, maintainer, homepage, description, and license metadata are updated accordingly; the executable installs to /usr/local/bin/silo-console.

Deliberately Retained Compatibility Identifiers

The following names retain minio or console as part of interface, protocol, or installation compatibility:

Upgrade scripts therefore must not run repository-wide minio → silo or console → silo-console replacements. Migrating these compatibility interfaces in the future will require aliases, deprecation windows, and an explicit dual-read strategy.

A Redesigned Interface

Version 2.0.0 redesigns the console interface end to end.

Login page

The login page is rewritten from scratch. The left brand panel renders a slowly drifting sine-mesh animation generated purely on Canvas (zero external dependencies, honors prefers-reduced-motion, pauses in background tabs), states the project’s proposition — “Keep the S3 Interface / Own the Object Store” — and keeps the full MinIO trademark notice at the bottom. The right-hand form is functionally untouched, preserving every existing automation selector. The Chakra Petch typeface used by the SILO wordmark ships as a ~20KB locally bundled subset with no external requests.

A unified theme system

All console colors converge into one light/dark theme layer: neutral greys for text and borders, the brand steel blue for primary actions and selection, and a sidebar that uses the same night palette as the login panel in both modes. Controls and cards share consistent radii and transitions, inputs get a keyboard focus ring, and modals animate in (also honoring reduced motion). Server-provided customStyles keep full precedence.

Console polish

• Dashboard (Metrics): stat cards rebuilt under one grammar — muted labels, tabular numerals, aligned status dots; charts and info strips are theme-driven; the upstream absolute-positioning layout is gone.
• Unified empty states: placeholder text in Watch, Trace, bucket Events/Replication/Lifecycle, and every other data panel is now centered and de-emphasized instead of raw top-left text.
• Vertical tabs: detail-page tabs change from bordered grey blocks to a quiet pill list, eliminating the stray empty cell at the bottom of the rail.
• License page: a new VERSION section shows both the connected server’s release and the Console’s own version; accounts without admin:ServerInfo never issue the request and the row stays hidden. The page also consolidates AGPLv3 licensing, the AGPL section-13 source offer, lineage, and trademark boundaries.
• A batch of interaction fixes: the sidebar now collapses on initial load at mobile widths (previously it waited for a resize event); the bottom navigation no longer lags window-height changes; the bucket accordion highlight spans the full row; the dashboard no longer overflows horizontally on narrow screens; and the help panel is now truly lazy — the login page makes no external requests at all.

Brand icon set

The favicon, PWA, and Apple Touch icons still carried a previous-generation hand-drawn emblem. 2.0.0 re-rasterizes every size (ico 16+32, favicon 16/32/96, apple 180, manifest 192/512) from the official silo.svg vector emblem, with safe-area margins on home-screen sizes, and trims the Web App Manifest to the modern icon set, dropping the 2014-era legacy density entries. The icon payload drops from 473KB to 160KB, and the browser tab icon finally matches the in-product brand.

Smaller and Faster

Embedded delivery is this console’s core form factor — the frontend ships inside the binary via go:embed. 2.0.0 optimizes that path systematically:

• Embedded payload: ~9.6MB → 3.5MB. Text assets (JS/CSS/SVG/…) are precompressed at build time with deterministic gzip and embedded compressed-only; legacy WOFF fonts (~1.25MB that no supported browser ever downloads) and a set of entirely unreferenced orphan images are removed.
• First-load transfer: ~5.7MB → ~1.7MB. Static assets previously shipped uncompressed on the wire; they are now emitted directly with Content-Encoding: gzip at zero runtime cost, with on-the-fly decompression for the rare client that does not accept gzip.
• Correct HTTP semantics. Accept-Encoding is parsed with full RFC 9110 q-values (gzip;q=0 gets identity bytes), responses carry Vary: Accept-Encoding, and non-GET/HEAD requests to static paths and the SPA entry receive 405 with an Allow header.
• Reproducible builds. Compression uses a pure-JS implementation (fflate) for byte-identical output across platforms, and the release pipeline enforces a hard gate: rebuilding the embedded assets in a clean environment must produce zero diff against the commit.

Release binaries (all frontend assets included, stripped) weigh roughly 35–40MB; for the downstream SILO server, embedding this console now costs about 3.5MB instead of about 10MB.

Security and Dependencies

Go: the build baseline moves to Go 1.26.5 and the golang.org/x family is fully refreshed. Every reachable vulnerability reported by govulncheck is resolved:

The single remaining advisory sits in golang.org/x/crypto, has no upstream fix yet, and is unreachable from this codebase; it is tracked as a known item.

Frontend: the full dependency-tree audit (production and tooling) is clean, covering the high-severity form-data CRLF injection and the DOMPurify and qs advisories; React Router is migrated to 7.18.2 (keeping the v6-compatible declarative API, with full routing regression). The only explicitly ignored advisory affects an unstable API this project does not use.

Runtime correctness: a real data race between HTTP log-target initialization and shutdown is fixed, along with shared-mock races in the test suite; supported Go packages pass -race across the board. As a side benefit, the go-m1cpu upgrade fixes the local go run cgo crash on recent macOS.

Update Checks and Default Network Behavior

This release keeps conservative defaults for upgrade tooling:

• automatic self-update in silo-console update is disabled — the command prints guidance and never downloads or replaces the binary;
• the release catalog gains SILO_RELEASE_SERVICE_HOST, with the previous RELEASE_SERVICE_HOST as a compatibility fallback; with neither set, no remote release service is contacted;
• the help panel’s blog content loads only when opened, and its links accept https://silo.pgsty.com exclusively.

Automatic updates will be reconsidered once signed release assets and a tested rollback path are in place.

Release Artifacts and Platform Matrix

The release ships 16 assets:

The pipeline triggers on tag pushes, pins third-party Actions to commit SHAs, and enforces the clean-checkout and zero-diff asset-rebuild gates before GoReleaser runs.

Upgrade Guide

Standalone binary

install -m 0755 silo-console-linux-amd64 /usr/local/bin/silo-console
/usr/local/bin/silo-console server

When building from source, make console still produces ./console; install it under the release name before wiring it into a production service.

DEB/RPM/APK and systemd

Packages continue to install /etc/systemd/system/minio-console.service, whose unit starts /usr/local/bin/silo-console. EnvironmentFile=/etc/default/console, console-user, and existing CONSOLE_* variables are unchanged. This retention lets package upgrades keep acting on the existing service instead of creating a parallel one.

Configuration and integrations

• do not rename CONSOLE_MINIO_SERVER or CONSOLE_MINIO_REGION;
• do not touch github.com/minio/console in Go imports;
• prefer SILO_RELEASE_SERVICE_HOST for self-hosted release catalogs;
• replace any reliance on console update with explicit download, verification, and deployment;
• update process-path-based monitoring to /usr/local/bin/silo-console.

This release does not change the object data layout and requires no bucket or object migration.

Validation Scope

Release verification covered Go -race across supported packages, go vet, golangci-lint, govulncheck, frontend type checks, production builds, Prettier, dead-code checks, full dependency audits, and the following integration checks:

• all 184 embedded files fetched three ways each (gzip client, identity client, HEAD) with per-file hash comparison against the embedded sources;
• RFC semantics probes (including combined q-values such as gzip;q=0, *;q=0.5), method restrictions, the OIDC callback, and SPA deep links;
• full React Router 7 regression: deep links, client-side navigation, bucket-detail tab switching, and browser history back;
• mobile first-load sidebar behavior, login-page external-request monitoring, and light/dark full-site tours;
• downloaded release assets verified byte-for-byte against checksums, binary self-reported version confirmed, and a smoke test of the published binary against a live server;
• zero-diff asset rebuilds confirmed on both macOS and Linux.

Known Limitations

• automatic self-update is disabled; upgrades are explicit;
• the SSO end-to-end suite requires an external OpenLDAP/Dex/MinIO topology and was not run in that environment this cycle (the OIDC code paths are covered by unit tests and HTTP-level checks);
• one golang.org/x/crypto advisory has no upstream fix yet and is unreachable from this codebase;
• SILO does not yet maintain its own video library; videos in the help panel are clearly labeled upstream compatibility material;
• administrative features depend on the MinIO-compatible Admin API — SILO Console is not a generic browser for arbitrary S3 services;
• retained Go module paths, environment variables, protocol fields, and the systemd unit name still appear in code, configuration, and process listings.

Related Commits and Links

The complete v2.0.0 change set consists of 8 logical commits:

• 50797de — feat: establish SILO Console identity and compatibility
• 23ae6e8 — feat: redesign and harden the SILO Console web app
• 7a83a77 — build: update Go toolchain and dependencies
• 1330d25 — fix: eliminate logger shutdown and test mock races
• 06b3a34 — docs: publish the SILO Console v2.0.0 guide
• 4b24372 — build: regenerate optimized embedded web assets
• c38eb64 — ci: package and publish SILO Console v2 releases
• b952a12 — brand: regenerate the icon set from the official silo.svg emblem

Links:

• SILO Console source · Releases
• SILO website · Documentation
• Licensing · Attribution · Trademark

2.21 - silo-pkg 3.13.0 Released

Release date: 2026-08-30 · Version: v3.13.0 · Commit: 215f116 · Repository: pgsty/silo-pkg

Version 3.13.0 is a breaking release: the module adopts github.com/pgsty/silo-pkg/v3 as its own import path and retires the pgsty/silo-go fork in favour of upstream minio-go. All maintained SILO components (silo, silo-console, and mcli) migrated to this module path in the 2026-09-03 / v2.4.0 release wave; see the component matrix.

Release at a Glance

• Published: the silo-pkg v3.13.0 tag and GitHub Release, declaring module github.com/pgsty/silo-pkg/v3.
• Retired: the github.com/minio/pkg/v3 module identity and the replace directive every consumer had to repeat.
• Retired: the github.com/pgsty/silo-go/v7 fork; this release requires upstream minio-go directly.
• Unchanged: every package, symbol, and behaviour. Only the path they are imported from moved.
• Downstream adoption: completed across SILO 20260903, Console v2.4.0, and mcli 20260903.

Why the Path Moved

The fork kept upstream’s github.com/minio/pkg/v3 path so it stayed a drop-in replacement, selectable with one replace directive. Go does not inherit replace directives from dependency modules, and three costs came due while preparing the next SILO server release.

Every consumer had to repeat the redirect, and one that forgot built against upstream silently. A module that requires this package but omits the replacement resolves the real minio/pkg, compiles, and quietly loses the fork’s behaviour.

The require line had to name a version the source no longer matched. ParseConfigStrict first appears upstream in v3.11.0, and Resource.IsBareARN exists in no upstream version at all. A require github.com/minio/pkg/v3 v3.6.1 next to source that needs v3.12 APIs is metadata that cannot be made true by editing the number.

Working around that propagated. pgsty/mc carried a compile-time sentinel — a reference to Resource.IsBareARN — purely to turn the silent downgrade into a build failure. Raising mc’s floor to make its metadata honest pushed the requirement through the module graph and forced silo-console’s deliberately low floor upward, which is exactly what that floor existed to prevent.

Upstream’s path had little to offer in return here. minio/pkg is a small internal library, and this module’s consumers are silo, silo-console, and mcli. The Silo Go SDK keeps upstream’s github.com/minio/minio-go/v7 path, where drop-in compatibility is worth having and upstream is actively maintained.

Upstream minio-go Replaces the Silo Go SDK

pgsty/silo-go no longer carried any functional divergence. Its one unique change, Return CopyObject checksums in UploadInfo, was merged upstream on 2026-08-24. Everything else in the fork was a version string, a logo, a README, and a lint-tool block.

Upstream’s newest tag v7.3.0 predates that merge by 14 commits, among them a data race fix in parallel multipart checksum hashing, so pinning the tag would be a regression. This release therefore requires the pseudo-version v7.3.1-0.20260828014306-0e78d3f18efe and will move to a tag when upstream cuts one.

Compatibility

Every package, exported symbol, and behaviour is unchanged. This release moves where they are imported from, nothing else.

Take it together with the matching silo, silo-console, and mcli changes. A consumer that upgrades alone will not build, because the old and new paths are different modules and types do not cross between them.

Before:

require github.com/minio/pkg/v3 v3.6.1

replace (
    github.com/minio/pkg/v3      => github.com/pgsty/silo-pkg/v3 v3.12.2
    github.com/minio/minio-go/v7 => github.com/pgsty/silo-go/v7 v7.3.1
)

After:

require github.com/pgsty/silo-pkg/v3 v3.13.0

…and rewrite github.com/minio/pkg/v3/... imports to github.com/pgsty/silo-pkg/v3/.... Consumers that stay on the old arrangement keep building against v3.12.2 and earlier, which remain published.

One consequence is worth expecting. Because the two paths are now separate modules, a build can contain both — a third-party dependency that imports github.com/minio/pkg/v3 no longer has its import redirected. In the SILO stack this happens once, through minio/colorjson and minio/dperf, both of which reach only pkg/v3/console. That package’s colour switch is fatih/color’s process-wide NoColor, which every copy shares, so disabling colour still disables it everywhere.

Verification

• go build ./..., go vet ./..., go mod tidy -diff, and gofmt -l . are clean; go test ./... passes 23 packages.
• CI on the release commit: Go, LDAP Config Validator, VulnCheck.
• The new path was resolved from the module proxy by a fresh module with no replace directive, which imported policy and ran.
• The downstream migration was validated end to end before this release: mcli (194 files), silo-console (36 files), and silo (181 files) all build, vet, and pass their suites. silo’s rebrand guard passes with a compatibility-baseline diff of exactly 19 deleted import entries and no change to environment variables, metrics, headers, routes, policy values, or exported symbols.

2.22 - silo-pkg 3.12.0 Released

Release date: 2026-08-24 · Version: v3.12.0 · Commit: 2b087a1 · Repository: pgsty/silo-pkg

Version 3.12.0 is a main-line minor release with two themes: a policy-write guard for ARN prefixes that name no resource, and the maintained Go 1.27 / etcd 3.7 dependency baseline. It adds two exported inspection/validation methods, raises the verified consumer floor to Go 1.26, and is the first silo-pkg release whose strict validation path is enabled by the SILO server (eee05a17c, SN-2026-005, shipped in SILO 20260903) for named-policy and service-account policy writes.

Release at a Glance

• Published: the silo-pkg v3.12.0 tag, GitHub Release, and strict library validation for bare ARN prefixes.
• Server integration: named-policy and service-account policy write validation in eee05a17c (SILO 20260903).
• Deliberately permissive: existing IAM policy loading, IAM import, and site-replication receive paths.
• Deferred: STS inline-policy strict validation and Console-side early validation; the server remains authoritative.

Bare ARN Prefixes Were Policy No-ops

An S3 resource ARN needs a resource after its namespace prefix:

arn:aws:s3:::my-bucket
arn:aws:s3:::my-bucket/*
arn:aws:s3:::*

The policy parser also accepted the prefix by itself:

arn:aws:s3:::

That string names no bucket or object. The existing parser normalized it to the wildcard resource type while retaining arn:aws:s3::: as the match pattern. Real S3 authorization candidates look like bucket or bucket/object, so the pattern normally matched nothing even though the policy validated successfully.

For statements that actually perform resource matching, the impact depends on Effect and on whether the prefix appears in Resource or NotResource:

The dangerous cases are policy-dependent fail-open behavior, not an unauthenticated remote exploit and not a CVE. A policy author, template, or automation must first submit the malformed resource. The same issue applies to registered S3 Tables and KMS ARN prefixes.

Resource-less admin actions, sts:* action statements, and the first phase of two-step KMS authorization bypass resource matching; a bare prefix does not change their existing runtime decision. Strict writes still reject the deceptive field so a policy cannot look scoped when that scope is ignored.

The Historical *arn:... Spelling

On the permissive compatibility path inherited from earlier releases, serializing a parsed bare prefix adds the wildcard type marker:

arn:aws:s3:::  ->  *arn:aws:s3:::

Re-parsing either spelling produces the same internal resource value. The 3.12 guard therefore recognizes both the exact prefix and its historical star-prefixed serialization. This matters for stored/exported policies and for clients that parse and marshal a document before sending it to the server.

The accepted wildcard corpus remains unchanged: *, **, ***, *foo, and explicit resources such as arn:aws:s3:::* still parse as before.

A Strict Write Path, Not a Storage Migration

The fix deliberately separates policy loading from policy creation:

• ParseConfig and Validate remain permissive. Existing stored policies keep loading and evaluating with the same matching and serialization behavior.
• ParseConfigStrict and ValidateStrict reject a registered ARN prefix that names no resource, in both Resource and NotResource.
• Resource.IsBareARN() detects the normalized exact/historical form without changing the exported Resource structure, ParseResource, matching, or JSON representation.
• ResourceSet.ValidateStrict() exposes the strict resource-set check to consumers.

Keeping the existing resource representation is important for mixed-version sites: v3.11 and v3.12 nodes continue to compare and serialize stored policies the same way, so this fix does not create a site-replication mismatch or require a storage migration.

SILO Enables the Guard on Three Boundaries

SILO commit eee05a17c selects silo-pkg v3.12.0 and uses strict parsing when:

1. creating or replacing a named IAM policy;
2. creating a service account with an inline session policy; and
3. updating a service account’s inline session policy.

Compatibility-sensitive paths stay permissive in this rollout:

• loading named policies and embedded policies already at rest;
• IAM import/restore;
• site-replication receive and apply paths;
• STS inline session policies; and
• bucket policies, whose existing bucket/action validation already rejects these forms.

Enabling ParseConfigStrict also activates two pre-existing admin-policy checks: one admin statement may not contain both Resource and NotResource, and a bucket-scoped admin action may not use a non-S3 resource. These are intentional authorization tightenings and are documented in the advisory ledger under SN-2026-005.

Operator Action

Existing policies are not rewritten automatically because the intended resource cannot be inferred. Before deploying a SILO server build that contains the strict integration:

1. inspect named IAM policies for exact or historical bare prefixes;
2. inspect service-account inline policies;
3. replace each finding with the intended concrete resource; or use a suffix wildcard only if all resources in that namespace are truly intended; and
4. repeat the audit after all sites have completed the rolling upgrade.

Do not blindly turn every finding into arn:aws:s3:::*: that could replace an inert statement with a cluster-wide grant or denial. A legacy policy containing a bare prefix still loads, but it cannot be submitted unchanged through the three strict write endpoints; correct it before editing another property on the same policy or service account.

The safer audit path uses policy-info and access-key-info APIs rather than a full IAM export, because a complete export contains user and service-account secrets. STS strict validation remains deferred until live machine clients and their session-policy templates can be audited separately.

Why This Is a Minor Release

This is v3.12.0, not v3.11.1, because the release combines three compatibility-relevant changes:

1. the etcd client crosses from the 3.6 minor line to 3.7;
2. the module’s verified go floor rises from 1.25.0 to 1.26.0; and
3. the package adds exported bare-ARN inspection and strict resource-set validation APIs.

The module path remains github.com/minio/pkg/v3; the /v3 import suffix and every existing import site stay unchanged.

Go and Dependency Baseline

The go and toolchain directives have separate purposes:

• go 1.26.0 is the supported consumer floor required by the selected etcd 3.7 modules.
• toolchain go1.27.0 is the maintained development and CI baseline.
• CI actions move to the Node 24 runtime.

Key selected versions change as follows:

Smaller selected updates include uax29 2.3.1, fastjson 1.6.10, secp256k1 4.4.1, and goccy/go-json 0.10.6. The old lestrrat-go/option v1, gogo/protobuf, and stale test-only requirements leave the selected graph.

etcd 3.7.1 is the first fixed release on the 3.7 line for GO-2026-6107 / CVE-2026-73500, an unauthenticated TLS-listener denial of service. Updating these Go client modules does not upgrade an operator’s external etcd server. SILO does not use the removed grpc.WithBlock behavior, and client compatibility with an etcd 3.6.14 server was exercised during release validation.

The dependency graph declares coreos/go-systemd 22.7.0, but the module replaces it with 22.6.0 because 22.7.0 does not compile on NetBSD. The SILO server carries the same portability override.

Compatibility

• Import paths and the module major remain unchanged.
• Existing policies keep loading and evaluating unchanged; only strict create/update calls reject the malformed prefixes.
• No policy, IAM database, wire protocol, or etcd data migration is performed.
• Downstream users of grpc.WithBlock in etcd client dial options must migrate to a supported readiness check; SILO does not use it.
• A real external etcd cluster upgrade remains a separate operational procedure.
• Upstream AIStor Memory and new AIStor-only S3 Tables action vocabularies are not imported by this fork.

Consumers select the release with:

require github.com/minio/pkg/v3 v3.12.0

replace github.com/minio/pkg/v3 => github.com/pgsty/silo-pkg/v3 v3.12.0

Verification

The tagged package passed:

• the repository’s complete make test gate: pinned lint plus go test -race -tags kqueue ./...;
• targeted bare-ARN tests repeated to disturb Go map iteration order; and
• go mod verify, go vet, git diff --check, and govulncheck with zero reachable vulnerabilities.

The SILO integration passed:

• the complete IAM server suite, including exact/historical named-policy rejection and service-account create/update rejection;
• go test ./cmd -count=1, go vet ./cmd, and go test ./...;
• golangci-lint 2.13.1 with zero findings, go mod verify, and make check-gen; and
• mutation tests proving all three strict call sites and their integration assertions are load-bearing.

Direct VCS module resolution verified v3.12.0 at commit 2b087a1 with module checksum:

h1:1Bjqjb3KCt0oYhBLpH7W/e/5khTUoIgXWA12An1fbUc=

The Git tag, GitHub Release, direct module archive, origin commit, and checksum were verified.

Related Changes

• 2bc3a91: move CI actions onto Node 24
• c8c6872: align the SILO Go dependency stack
• 2b087a1: reject bare ARN prefixes on strict policy writes; tagged v3.12.0
• 30c49bd: update the README dependency example after the tag
• eee05a17c: enable strict named-policy and service-account writes in SILO
• 56c67dacf: record SN-2026-005

Server Release Scope

The server-side strict policy-write integration (eee05a17c) shipped in SILO 20260903. STS inline-policy strict validation remains deferred so machine clients and session-policy templates can be audited separately.

2.23 - Silo Pkg 3.11.0 Released

Release date: 2026-08-04 · Version: v3.11.0 · Commit: d8b1fa7 · Repository: pgsty/silo-pkg

This is the fork’s first pinned release. It restores the IAM bucket/object resource boundary reported as upstream minio/minio#20449: a policy condition-key bypass fix, three LDAP connection defects, a certificate watcher leak, a seeded-RNG defect, and the module’s real minimum Go version.

What This Repository Is

silo-pkg is a maintained fork of minio/pkg, carrying fixes needed by community MinIO forks that the now commercially driven upstream no longer accepts. The repository was renamed from pgsty/minio-pkg on 2026-08-02.

The module path intentionally remains unchanged as github.com/minio/pkg/v3. Existing import "github.com/minio/pkg/v3/..." statements do not change; only the right-hand side of the replace directive does:

replace github.com/minio/pkg/v3 => github.com/pgsty/silo-pkg/v3 v3.11.0

The /v3 suffix is the module’s major version, not a directory name, and must not be omitted. It is also why this release is numbered v3.11.0 rather than v4.0.0: Go requires the major version of a tag to match the major-version suffix declared in go.mod, so a v4.0.0 tag on a .../v3 module is rejected by the toolchain. Publishing a real v4 would mean changing the module path and rewriting roughly 395 import sites across the server, mc and Console — abandoning the drop-in property that is the point of keeping upstream’s path.

The IAM Bucket/Object Boundary

Every bucket-level S3 operation authorizes with an empty object name. The IAM matcher turned that into a resource string and, for the empty-object case, appended a trailing slash:

resource.WriteString(args.BucketName)
if args.ObjectName != "" {
    // "bucket/object"
} else {
    resource.WriteByte('/') // "bucket/"  <-- the defect
}

"bucket/" is matched by the wildcard pattern "bucket/*", because * matches the empty string. A policy granting s3:* on arn:aws:s3:::bucket/* — which reads as “anything, but only on the objects in this bucket” — therefore also authorized bucket-level actions. In a multi-tenant cluster, a tenant holding only that grant could call PutBucketPolicy and install {"Principal":"*"}, making the bucket publicly readable or writable, or grant itself bucket-level control. It could also delete the bucket outright, which is the reproduction in the upstream issue.

The bucket-policy evaluation path used for anonymous access never had this slash and was already reference-correct. Only the IAM path was wrong, in exactly one place.

Why not correct the whole boundary

Removing the slash for every bucket-level request is the obvious fix, and upstream tried it: the change was reverted the same day for breaking policies that relied on the old behaviour. Two properties make the full correction a migration rather than a patch.

It revokes grants real deployments depend on. It does not only revoke the dangerous bucket writes — it also revokes ListBucket, GetBucketLocation and ListBucketMultipartUploads when granted through bucket/*. The evidence is upstream’s own test suite: eleven STS integration tests grant s3:ListBucket on bucket/* and then assert that listing works. If the project that wrote the server writes it that way, production policies do too.

It cuts both directions. The matcher builds the same resource string for Allow and Deny, so removing the slash tightens over-granting Allow statements and simultaneously loosens over-blocking Deny statements. An administrator who locked a bucket with Deny s3:* on bucket/* would silently lose that protection.

How the protected set was chosen

The scope was decided by one question: does reaching this action give the caller something its object-scoped grant does not already provide?

That question is the right one because of how the defect fires. Resource matching runs after action matching, so the bug only bites when the statement already grants the bucket-level action — which in practice means s3:*. The affected principal therefore already holds full read, write and delete over every object in the bucket. The relevant question is what reaching a bucket action adds to a caller that already controls all object data in the bucket.

Withheld from object-only grants (twelve actions):

Deliberately not withheld, and asserted by a test so that adding one is a deliberate act with a visible cost rather than an edit to a list:

• PutBucketTagging, PutBucketEncryption, PutBucketNotification. These are bucket-level writes and an earlier draft did withhold them. None gives the caller access it does not already hold — the harm is to the owner’s posture, not to the access boundary — while a tenant handed s3:* on bucket/* and told the bucket is theirs may quite reasonably tag it, set default encryption, or wire up event notifications. Low security gain against a real compatibility cost is the wrong trade for a maintenance release.
• CreateBucket. It targets a bucket that does not exist yet, so there is nothing to mutate or destroy, and provisioning flows commonly create a tenant’s bucket with that tenant’s own bucket/* credentials.
• The read/list family (ListBucket, GetBucketLocation, the configuration reads). Breaking these is what got upstream’s own attempt reverted. They wait for a migration-gated release.

Only Allow statements are affected. Deny statements keep the historical resource string, so no bucket lock is ever weakened, and NotResource exclusions keep their full reach.

Monotonicity, and the claim that was wrong twice

All of the above rests on one property: this change may remove permissions and must never add one. That property was asserted twice from reasoning rather than from tests, and was false both times. Recording how is more useful than recording only the final state.

The first attempt let the withheld slash reach the NotResource match as well — and NotResource is an exclusion. An Allow s3:* NotResource bucket/* statement historically did not apply to bucket-level requests on that bucket; matching the exclusion against the bare bucket name made it stop matching, so the Allow it qualified grew, for exactly the writes being protected.

The second attempt fixed that and shipped saying the result was provably monotone. Testing against fixed-width wildcard patterns exposed a counterexample. Withholding the slash changes which string patterns are matched against, and a pattern can match "mybucket" without ever having matched "mybucket/". A fixed-width wildcard is the clean case:

Allow s3:PutBucketPolicy on arn:aws:s3:::mybucke?

? matches exactly one character. Against the nine-character "mybucket/" it does not match, so this statement never authorized the bucket-level write. Against the new eight-character "mybucket" it does, so the hardening granted something the buggy matcher refused.

On the protected path the matcher now requires both forms to match — the bare bucket name and the historical "bucket/". The result is an intersection with the historical decision, so it is monotone by construction: there is no pattern it can newly satisfy. mybucket* still grants (it matched both all along), mybucket/* is still withheld, and mybucke? is refused as before.

Evidence

The property is verified rather than argued. A decision corpus of 27,000 authorization outcomes — 15 resource patterns × 3 buckets × 5 object names × 20 actions × 6 statement forms — was generated against both the pre-hardening baseline and this release and compared entry by entry:

Every one of the 144 narrowed outcomes falls inside the design intent, with nothing outside it: exactly the twelve protected actions; only the three Allow statement forms, with zero transitions for Deny, NotResource-excluded or deny-NotResource forms; only four object-only resource patterns; and only bucket-level requests, with object-level requests entirely untouched. 12 × 4 × 3 = 144, fully accounted for.

Regression coverage exists at both layers. In this repository, twelve matcher tests pin each direction, including an invariant test that every protected action really is bucket-only — ResetBucketReplicationState, despite its name, is an object action and stays out. In the server, three end-to-end tests drive the real handlers at the client, inline-session-policy and S3-router levels; all three fail against the pre-fix build and pass against this one.

What to change

You are affected only if a stored policy grants one of the twelve actions — or s3:* — on a resource pattern containing /, with no bare bucket ARN for the same bucket. The fix is to add the bare ARN alongside the object pattern:

"Resource": ["arn:aws:s3:::bucket", "arn:aws:s3:::bucket/*"]

That pairing is the conventional form, is what upstream’s own tests use, and worked before this release as well. Built-in canned policies are unaffected — readwrite, readonly, writeonly and diagnostics all use Resource: "*".

MINIO_API_LEGACY_BUCKET_RESOURCE_MATCH=on, read once at startup, restores the historical matching in full — both the over-granting and the over-blocking. It is a single global switch; per-action scoping is deferred.

Policy Condition-Key Lookup Order

getValuesByKey() previously looked up a policy condition key by its canonical MIME spelling (http.CanonicalHeaderKey) before trying the original name. The map it reads mixes values calculated by the server for the current request (SourceIp, SecureTransport, CurrentTime, username and others, stored under condition-key spellings) with HTTP headers supplied by the request (stored under canonical MIME spellings).

Checking the canonical spelling first allowed a client header to override a value calculated by the server.

For a MinIO server this is a policy bypass. The simplest example is s3:prefix: a Prefix request header could satisfy a home-directory prefix condition while the real ?prefix= query parameter still listed the entire bucket. The same path reached aws:SourceIp, aws:SecureTransport, aws:CurrentTime, aws:EpochTime, aws:username, aws:userid, aws:principaltype, aws:UserAgent, aws:groups, ldap:username, ldap:groups, jwt:groups, s3:versionid, s3:signatureversion, s3:signatureAge, s3:authType and s3:LocationConstraint. Anonymous bucket policies were directly exposed. SigV4 did not prevent the attack because a client can add a header that is not listed in SignedHeaders.

There was a second consequence: when the server stored a value under one spelling and the policy key resolved another, the wrong entry won. s3:object-lock-mode could resolve to the caller’s X-Amz-Object-Lock-Mode header rather than the retention mode the server would actually apply.

The fix reverses the lookup order: match the condition key’s exact name first, then use the canonical spelling only as a fallback for condition keys that genuinely name request headers, such as the s3:x-amz-* family. This ports minio/pkg#226 and adds regression coverage the upstream change did not carry.

At the library’s raw-map layer, if a producer stores one logical field under both the exact condition name and its canonical MIME name, the exact name now wins. This is a library lookup rule, not an S3 wire-protocol rule that says query parameters take precedence. The Silo server first normalizes condition values by their real source. For storage class and upload tagging, where both Header and query forms remain compatible, Header presence wins, including an empty value; query is only the fallback.

LDAP Connection Path

Three defects in connect(). Two were introduced by this fork in b0c08a7 and shipped in v3.6.2 and v3.6.3. Users of either release should upgrade promptly.

StartTLS was skipped when ServerInsecure was enabled. Upstream called StartTLS in an outer block controlled only by ServerStartTLS, so enabling both options created a plaintext connection and then upgraded it. b0c08a7 moved the call into an else branch, making StartTLS unreachable whenever ServerInsecure was true. The connection stayed plaintext and the following bind sent credentials over it. MinIO exposes MINIO_IDENTITY_LDAP_SERVER_INSECURE and MINIO_IDENTITY_LDAP_SERVER_STARTTLS independently and Validate() rejects no combination, so this state was reachable.

This release restores the upstream semantics: the two switches are additive, not mutually exclusive. ServerInsecure disables implicit ldaps://; ServerStartTLS still performs the upgrade. The exposure window is limited to v3.6.2 and v3.6.3.

A Config without a TLS section could panic on the ldaps:// path. After l.TLS.Clone() moved outside the StartTLS branch, ordinary ldaps:// connections also called it. Clone() returns nil for a nil receiver, but the next line assigned ServerName. The MinIO server always supplies TLS settings, but this is a library and mc also consumes it. The code now falls back to an empty tls.Config, matching what DialURL would have built.

StartTLS had no deadline. go-ldap only starts its request timer when requestTimeout > 0, while StartTLS itself has no timeout. A server that completed TCP setup and then stopped responding to the extension request could hold the connect goroutine forever. The timer is now armed before StartTLS.

A failed StartTLS leaked the connection. Inherited from upstream. Dial failures do not return a connection, making StartTLS failure the only connect() path that could return both a connection and an error. Callers only took ownership when the error was nil, leaving a socket behind for every login attempt against a server with a broken upgrade. The failure path now closes the connection and returns nil.

Other Fixes

• certs: file watchers were never stopped. Manager.AddCertificate() registered two notify.Watch() calls and stopped neither: if the second failed, the first leaked, and both survived until process exit after the manager closed. Certificate.Watch() and watchFile() had the same problem. All four paths now use watchDirSafe(), which returns a stop function invoked on errors and ctx.Done(). This ports the certs/ part of minio/pkg#228. On Windows the function replaces filesystem notification with polling rather than using polling only as a failure fallback, so certificate reload can lag by one symlinkReloadInterval (10 seconds). This fork has no Windows CI; that platform was only cross-compiled.
• rng: reader subkeys came from a zeroed local variable. init() read 32 bytes of entropy into r.tmp but derived four subkeys from a same-named zeroed local, collapsing four per-block streams into one. Reset() and ResetSize() then replayed the previous stream byte for byte. MinIO creates a new reader for each randreader.New() call and never resets it, so the practical server impact is limited; warp exposed the defect. This ports minio/pkg#230.
• xtime: Duration implemented UnmarshalJSON but not MarshalJSON. Encoding produced an integer number of nanoseconds while decoding unconditionally stripped the first and last byte and expected a quoted string, so neither direction could round-trip. It now encodes using time.Duration’s string form. This ports minio/pkg#242.

Compatibility Impact

• Twelve bucket-level write actions are no longer authorized through an object-only resource pattern. See What to change. Object access, ListBucket, CreateBucket, bucket tagging, default encryption and event notification are all unaffected, as are Deny statements and NotResource exclusions.
• The minimum Go version moves from 1.26.1 down to 1.25.0. A patch number in the go directive is a hard minimum for every consumer, not a record of the toolchain used to build the module. The conventional split is a language version on the go line and a development version on a separate toolchain line. 1.25.0 is what the dependency graph actually requires and what upstream declares. CI builds the complete test suite with Go 1.25 under GOTOOLCHAIN=local, so the minimum is proven rather than aspirational.
• The JSON wire format of xtime.Duration changes from a nanosecond integer to a duration string such as "2h" or "30m". Persisted numeric values can no longer be read back. No such use was found in MinIO or mc: batch job definitions persist as YAML and the msgp path remains int64.
• Deployments with both ServerInsecure and ServerStartTLS enabled whose LDAP server does not support StartTLS connected successfully in plaintext on v3.6.2/v3.6.3 and now fail to connect. That is the correct result, but it surfaces during connection rather than configuration validation. Disable ServerStartTLS for such a server.
• Policy.IsAllowedActions can disagree with a direct decision for the twelve protected actions. It enumerates SupportedActions, which includes the s3:* pattern itself, so the returned set can contain s3:* — and therefore appear to permit a protected action — while the direct evaluation denies it. Nothing in the server calls it, and Console calls it with an empty bucket name, which never reaches the hardened branch. Recorded rather than changed, because altering a public API’s output in a maintenance release is the larger risk.

Divergence from Upstream v3.11.0

The version number follows upstream’s line and makes no claim of identical content. The measured delta, comparing action-string constants across policy/:

24 actions exist only upstream: six s3:*ObjectAnnotation* actions, five admin: actions (DistJobStatus, Get/SetBucketCompression, two TablesReplication*), and thirteen s3tables: actions covering function CRUD and tagging. These belong to the AIStor vocabulary this fork deliberately does not carry, because the community server does not implement them.

Three actions are named differently on each side. Upstream renamed and split these; this fork retains the earlier names:

A policy naming any of these six action strings therefore validates on exactly one of the two. Nothing in the Silo server, mc or Console references them, so there is no impact inside this ecosystem — but a consumer swapping upstream v3.11.0 for this release should know the vocabulary is not interchangeable.

rng has no arm64 assembly. Upstream added rng/xor_arm64.{go,s} after this fork’s divergence point; this release falls back to the pure-Go xor_noasm.go path on arm64. The result is correct and cross-compiles cleanly, but slower than upstream on that architecture. It is a clean candidate for a future sync, being a pure performance change with no vocabulary entanglement.

Companion Server Behavior

• The condition-key change in this release must be paired with the server changes that reserve internal condition-key names and populate values by semantic source, as noted at the top.
• s3:signatureAge is exposed only after the SigV4 presigned-request verifier calculates it. A client-supplied x-amz-signature-age Header is ignored on every other request type.
• s3:prefix, s3:delimiter and s3:max-keys come only from query parameters. Content hash, copy source, metadata directive, SSE and object-lock conditions come only from the corresponding headers. The X-Amz-Content-Sha256 query value consumed while verifying a presigned request does not become a policy condition.
• s3:x-amz-storage-class retains its compatible query form, as do request tags on PutObject and CreateMultipartUpload. For both fields, Header presence wins and query is used only when the Header is absent.
• s3:ExistingObjectTag/* comes only from tags loaded from the stored object, so a request’s own X-Amz-Tagging can no longer impersonate existing object state. PutObject, CreateMultipartUpload and PutObjectTagging bind s3:RequestObjectTag/* to the tag input those handlers consume. Other action paths retain the historical X-Amz-Tagging Header fallback for compatibility, so treat request-tag conditions as constraints only where the API actually consumes tags.
• aws:SourceIp is calculated from forwarding headers. Whether it is enforceable depends on the server’s trusted-proxy configuration; see the server’s own release notes for MINIO_API_TRUSTED_PROXIES.

Verification

Everything below was run against the tagged commit, with the working tree clean and the tag pointing at HEAD:

• make test — golangci-lint plus go test -race -tags kqueue ./..., all packages passing.
• go mod tidy -diff clean; gofmt -l empty; go vet ./... clean.
• Cross-compilation for linux/amd64, linux/arm64, darwin/arm64 and windows/amd64.
• govulncheck ./... — zero reachable vulnerabilities. One module-level notice remains, GO-2026-5932 in x/crypto/openpgp; that package is unmaintained, has no fixed version, and this repository does not import it.
• Resolution from an empty module cache through the public proxy, confirming the release is fetchable as published.
• The 27,000-outcome authorization corpus described above.

Dependencies and Tooling

Dependency updates clear nine reachable findings previously reported by govulncheck: seven x/crypto/ssh issues reached through sftp, GO-2026-6061 in gRPC reached through etcd, and GO-2026-4945 in go-jose reached through oidc.

Five dependencies — minio-go, minio/mux, etcd client/v3, go-oidc and lestrrat-go/jwx — were deliberately not upgraded. MinIO consumes this module through replace, and Minimal Version Selection chooses the highest version in the entire graph, so upgrading them here would also pull the server forward. None has a reported vulnerability requiring that change.

All three workflows previously asked setup-go for a Go version lower than go.mod required and failed on the first Go command; they are now aligned. The linter also fetched an installer from the master branch and reinstalled it on every run. The URL and version are now pinned to v2.11.3, and a matching installed version skips the download.

Changes Deliberately Not Taken from Upstream

• AIStor policy vocabulary (Memory/cortex, Tables/Iceberg, KMS, compression and annotations) and the typed action-constant refactor, none of which the community server implements. This is the source of the action-vocabulary delta.
• securityAuditAdmin, which grants admin:ExportIAM and therefore exposes every secret key despite what the name suggests.
• rng AVX2/NEON assembly. Revisiting the arm64 half is noted above as a future sync candidate.
• net.BandwidthBytesPerSec (declared but never read upstream), replicationAdmin and DistJobStatusAction.
• Two changes initially taken and removed after review: the consolereadonly built-in policy and GetAllGlobalCertificates. Neither has a consumer. Once operators bind a built-in policy name to users, withdrawing it is particularly unsafe: policy mappings persist by name, and an unresolved name merges into an empty policy that denies everything. Its inherited admin:CreateUser Deny also cannot be combined with iamAdmin. The certificate helper inventoried a cache the community server never populates.
• Upstream’s golangci-lint tool directive, which would add roughly 200 linter dependencies to every downstream consumer’s module graph.

Deliberately Deferred

The general problem in minio/minio#20449 — that bucket/* still reaches ListBucket, GetBucketLocation, the configuration reads, CreateBucket and the three tenant-plausible writes — is not closed here. Closing it means revoking grants real deployments depend on, so it belongs to a release that carries a migration path.

What that release owes operators is more than a longer action list, because no one can enumerate every deployment’s stored policies — which puts a hard ceiling on any approach that picks the protected set by guessing. Three things raise it:

• A startup policy audit that walks stored policies and names each one whose meaning changes, in both the grant and the deny direction. It is read-only and can ship before the enforcement change rather than with it, turning an upgrade surprise into a pre-upgrade checklist.
• A denial that explains itself. When a request is refused because only an object-scoped grant matched, say so and name the compatibility switch. A break an operator can diagnose in thirty seconds costs an order of magnitude less than a silent one.
• A switch with a scope. MINIO_API_LEGACY_BUCKET_RESOURCE_MATCH is all-or-nothing today, so an operator who needs one action back must reopen the self-escalation path along with it.

Related Commits

• d8b1fa7: fix(policy): settle the bucket-write hardening’s scope and monotonicity
• 1f97549: fix(policy): extend the bucket-write hardening to every bucket-only write
• 3c24ad1: fix(policy): withhold object-only grants from sensitive bucket writes
• da6a22a: docs: say what this fork is and how to depend on it
• 4055b2f: fix(xtime): marshal Duration as a duration string
• 13c26cd: fix(rng): initialize the reader subkeys from the seeded entropy
• 88b37ac: fix(certs): stop file watchers on every exit path
• 74dd36e: fix(ldap): keep StartTLS when ServerInsecure is also set
• 424c3d0: fix(ldap): close the connection when StartTLS fails
• 045d10f: fix(ldap): guard a nil TLS config and arm the StartTLS deadline
• 5c4bf50: fix(policy): prefer the exact key name over the canonical header form
• 802539f: chore(deps): refresh the dependency set and declare the real minimum Go
• e4ec64a: ci: build on the Go version go.mod requires, and prove the declared minimum
• 747d8b8: build: pin the golangci-lint installer and skip a matching install

2.24 - Silo 20260903 Released

Version date: 2026-09-03 · Published: 2026-09-04 · Version: RELEASE.2026-09-03T13-18-01Z · Previous release: RELEASE.2026-08-06T00-00-00Z

SILO 20260903 is the security and correctness release following the first fully rebranded Silo release. It tightens core server invariants: client headers do not create replication authority, browser origins cannot trigger bucket-metadata I/O before authentication, concurrent bucket-configuration writers cannot silently overwrite one another, and authorization and checksum behavior more closely match AWS S3.

This note consolidates the complete server, Console, shared-package, and client baseline delivered on 2026-09-03 relative to 20260806. Later fixes—including SN-2026-011—shipped in SILO 20260916, SILO 20261015, and SILO 20261018.

Highlights

• Replication trust is authorization-derived. X-Minio-Source-Replication-Request and related internal fields gain replication semantics only after signature verification, an exact marker check, and s3:ReplicateObject or s3:ReplicateDelete authorization. Untrusted fields are stripped after authentication so SigV4 remains valid.
• Per-bucket CORS is complete. PUT, GET, and DELETE ?cors persist a real bucket policy, override the server-wide fallback, and converge through site replication. The pre-authentication lookup is resident-only and remains fail-closed during startup and after a known metadata-load failure.
• Bucket metadata updates are serialized. A shared metadata.lock covers all whole-record configuration writers, migrations, imports, site adoption, and healing. ForceCreate no longer erases existing configuration, and an Object Lock document always implies plain Enabled versioning.
• Authorization matches the requested operation. Explicit version deletion requires s3:DeleteObjectVersion; user and group enable/disable calls require the action matching the requested status; policy writes reject empty ARN namespaces.
• Checksum behavior moves toward AWS S3. Upload parts can receive server-computed checksums, federated UploadPartCopy returns its checksum, multipart completion reports ChecksumType, invalid assertions use AWS-compatible failures, and CRC64NVME with COMPOSITE is rejected.
• SSE-C reads and copies authenticate the key consistently. Zero-byte objects and GetObjectAttributes no longer bypass key validation; null-version rewrites and in-place key rotation no longer leave unreadable ciphertext or inconsistent checksum metadata.
• The release was simplified before publication. Dead code and obsolete lint exemptions were removed, compatibility snapshots now track served surfaces instead of source-level noise, dependencies were pinned to reviewed revisions, and flaky timeout tests received a private random source.
• The client release is part of the same baseline. mcli 20260903 adds read-only checksum verification, fail-closed credential redaction, repaired JSON metrics and S3 Select behavior, strict policy writes, signed packages, provenance, and verified amd64/arm64 images.

Security fixes

The repository security ledger assigns stable local identifiers to five findings without CVEs. An SN- identifier is not a CVE. The complete threat models, compatibility effects, and operator actions are collected in SILO 20260903 Security Notes.

All five defects were inherited from the archived upstream server lineage and affect every earlier SILO release. SN-2026-008 completes the receiver-wide repair begun by CVE-2026-34204.

The embedded Console v2.3.0 line also contains a trusted-proxy boundary, TLS verification repair, response and log redaction, and bounded WebSocket forwarding.

S3 correctness and interoperability

Multipart checksums

This release closes the multipart interoperability group reported in #46, #47, #48, and #50:

• UploadPart computes the selected checksum when the client selects an algorithm at upload creation but omits a per-part checksum header.
• UploadPartCopy returns the remote checksum through a legacy federated backend instead of dropping it.
• CompleteMultipartUpload includes ChecksumType and uses AWS-compatible error codes when a checksum is absent, malformed, contradictory, or unsupported.
• Unknown checksum algorithms and the invalid CRC64NVME + COMPOSITE combination are rejected rather than silently canonicalized.

The fixes are deliberately layered. The wire parser rejects invalid declarations, the multipart state records the selected algorithm and type, and completion validates the final claim against that state. Ordinary clients that do not opt into additional checksums are unchanged.

The individual evidence records are server-computed UploadPart checksums, multipart completion error semantics, and ChecksumType propagation.

CopyObject and SSE-C

CopyObject now:

• calculates checksums over the logical object before optional compression;
• returns the checksum fields in its response;
• preserves transform state on metadata-only copies;
• decrypts source checksum metadata with the source key and rewrites it for the destination key;
• handles null-version copies in either pool direction without losing current-version metadata;
• re-encrypts an in-place SSE-C key rotation when the object layer must rewrite the data.