PGSTY SILO Blog

• 1: Posts
  • 1.1: MinIO Fork, Promise Kept
  • 1.2: MinIO Is Dead, Long Live MinIO
  • 1.3: MinIO Is Dead. Which Next?
  • 1.4: MinIO is Dead
• 2: Release Notes
  • 2.1: SILO Console 2.4.1 Released
  • 2.2: silo-pkg 3.14.1 Released
  • 2.3: mcli 20260916 Released
  • 2.4: mcli 20260913 Released
  • 2.5: silo-pkg 3.14.0 Released
  • 2.6: SILO Console 2.4.0 Released
  • 2.7: Silo Console 2.2.0 Release Notes
  • 2.8: Silo Console 2.1.0 Released
  • 2.9: Silo Console 2.0.0 Released
  • 2.10: silo-pkg 3.13.0 Released
  • 2.11: silo-pkg 3.12.0 Released
  • 2.12: Silo Pkg 3.11.0 Released
  • 2.13: Silo 20260903 Released
  • 2.14: Explicit Version Deletes Now Require DeleteObjectVersion
  • 2.15: mcli 20260903 Released
  • 2.16: mcli 20260806 Released
  • 2.17: Silo 20260806 Released
  • 2.18: Silo 20260804 Released
  • 2.19: mcli 20260804 Released
  • 2.20: Silo 20260618 Released
  • 2.21: Silo 20260417 Released
  • 2.22: Silo 20260325 Released
  • 2.23: Silo 20260321 Released
  • 2.24: Silo 20260314 Released
  • 2.25: Silo 20260214 Released
  • 2.26: Silo 20251203 Released
• 3: SILO Security Chronicle
  • 3.1: September Security Repairs: Payload Integrity, IAM Revocation and Console Sharing
  • 3.2: SN-2026-011: Fix and Release Status
  • 3.3: CVE-2025-62506: Session-Policy Privilege Escalation
  • 3.4: SILO 20260903 Security Notes: SN-2026-006 through 010
  • 3.5: CVE-2026-32285: The jsonparser Advisory That Required No Patch
  • 3.6: CVE-2026-33322: OIDC JWT Algorithm Confusion
  • 3.7: CVE-2026-33419: LDAP STS Enumeration and the Throttling Chain
  • 3.8: CVE-2026-34204: Replication Metadata Injection
  • 3.9: CVE-2026-39414: Oversized S3 Select Records and a SIMD Bypass
  • 3.10: CVE-2026-40344: Snowball Auto-Extract Authentication Bypass
  • 3.11: CVE-2026-41145: Unsigned-Trailer Query Authentication Bypass
  • 3.12: CVE-2026-42600: ReadMultiple Storage-REST Path Traversal
  • 3.13: Internode Path Containment Audit: Paying Off What CVE-2026-42600 Left Owing
  • 3.14: The Parser Knew, the Schema Didn't: Config Keys That Could Take Every Notification Down
  • 3.15: Object Grant, Bucket Reach: When 'bucket/*' Could Rewrite the Bucket Itself
  • 3.16: Absent Is Not Empty: A Blank versionid and the Fail-Open It Invites
  • 3.17: Three Headers, One Lie: Making the Client Source Address Mean Something
  • 3.18: Sorted Is Not Increasing: How One Duplicate Part Number Doubled an Object
• 4: Design Records
  • 4.1: Bucket Configuration Replication: Source Times, Deletions, and Deterministic Convergence
  • 4.2: An Unsigned Header Is Not Part of the Request
  • 4.3: Durable IAM Revocations
  • 4.4: Federated CopyObject: Preserve the Destination Contract
  • 4.5: Multi-Pool Object Consistency
  • 4.6: Object Lock Replication Ordering
  • 4.7: SSE-C Replica Integrity
  • 4.8: Replication Reliability: Delete Completion, MRF Visibility, and Resync Cancellation
  • 4.9: Replicated Tag Ordering: Revision Timestamps, Tombstones, and Resurrection
  • 4.10: SILO Server 20260903 Pre-release Review
  • 4.11: Replica Metadata Normalization: What a Trusted Copy May Not Re-Inject
  • 4.12: Request-Header Deadlines: Absolute Header Limits and Rolling Body Idle Timeouts
  • 4.13: Conditional DELETE: One Condition, One Logical Object
  • 4.14: DSN-Only Database Notifications: A Compatibility Boundary for #53
  • 4.15: Preview Text, Never Execute It: SILO Console Text Preview PRD
  • 4.16: Go 1.27 TLS Defaults and OIDC Discovery Failure Modes
  • 4.17: No I/O Before Auth, No Privilege From Headers
  • 4.18: One Endpoint, Two Privileges: Separating User and Group Status
  • 4.19: Config Environment Files Are Not Shell Scripts
  • 4.20: Two SSE-C Keys, One CopyObject Response
  • 4.21: Why CompleteMultipartUpload Must Return ChecksumType: Review of PR #57
  • 4.22: When the Total Is Unknown: Folder Download Progress
  • 4.23: A ListObjects Shortcut Must Not Turn a Missing Bucket into an Empty One
  • 4.24: Read-Only Checksum Audit and Reliable CLI Output
  • 4.25: Optional Checksums, Mandatory Failure: Repairing UploadPart and UploadPartCopy Compatibility
  • 4.26: BadDigest, InvalidRequest, and the CompleteMultipartUpload Checksum Contract
  • 4.27: ListMultipartUploads: Implementation, Upgrade Contract and Design History

1 - Posts

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

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

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

• Docker: swap minio/minio for pgsty/minio.
• 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.2 - 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.

If you’re running MinIO, swap minio/minio for pgsty/minio. 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/minio is live on Docker Hub. docker pull pgsty/minio 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/minio.

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.3 - 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.4 - 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

Each published SILO version has its own page with the release date, major changes, security fixes, dependency updates, and related commits.

2.1 - 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 official container image is on Docker Hub, with Linux amd64 and arm64 support:

docker pull docker.io/pgsty/silo-console:v2.4.1

The release contains 44 assets: binaries and bundles, DEB/RPM/APK packages, source, legal notices, SPDX SBOMs, a checksum manifest and its Sigstore bundle. Checksums and the OCI image use keyless Cosign signatures; GitHub provenance records the build workflow and tagged release inputs. The image’s latest tag advances only after the published release passes signature, provenance, SBOM and anonymous-access checks. See the release contract for online and offline verification.

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.2 - 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. The package’s env JWT path uses registered claim names; dependency presence alone does not establish an exploitable mcli path.
• 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. The fix applies to the SDK’s CopyObject path; it does not establish every application’s selection of that path.
• 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.

mcli 20260916 and Console 2.4.1 select this package. The Server source baseline reviewed on September 16 still selects v3.14.0; publishing a module does not update a compiled Server. The component matrix separates published components from the next Server’s selected dependencies.

Release verification is recorded in the linked release and PR #9. Those records are upstream release evidence, not a new execution of their tests by this documentation update.

2.3 - 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. Per-object success start messages and progress byte counters are not proof that a transfer completed. 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. Upgrading only mcli does not update an installed Server or Console, alter Server authorization, or replace a client bundled in an existing Server image. 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 normally use ComposeObject; this fix does not substitute for separate evidence for that path.

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.4 - 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. This mcli release alone does not change an installed Server’s action mapping. September 16 follow-up: the matching password UI is released 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; that output correction is not limited to empty input.

2.5 - silo-pkg 3.14.0 Released

v3.14.0 was published on 2026-09-13 from 827f8109. It is consumed directly as github.com/pgsty/silo-pkg/v3.

Password-policy migration

This release changes authorization semantics. The public Policy.IsAllowedActions method now reports admin:ChangeMyPassword unless explicitly denied; admin:CreateUser requires an explicit Allow. With matching Server/Console source, a CreateUser deny alone no longer locks the caller’s password, while a ChangeMyPassword deny does.

The built-in readonly drops its CreateUser deny. A separate CreateUser Allow can therefore become effective; the added consolereadonly follows the same split and includes bucket listing. Neither policy grants user administration by itself. Saved policies and overrides are not rewritten.

To preserve the old combined restriction, retain both actions in the same Deny statement, including its original scope and conditions, before upgrading and throughout rollback. Old Servers do not enforce a password-only deny for this endpoint. Read the full migration guide.

September 16 follow-up: Console v2.4.1 ships the matching password UI with pkg v3.14.1 and mcli 20260916. Follow the component matrix for the coordinated upgrade.

Dependencies and verification

• Upstream minio-go is pinned to v7.3.1-0.20260910142817-60bd07042d49: configurable upload limits, streaming Content-Type signing, caller TLS trust for RDMA, consistent listing checksums and optional restore status.
• Go x/* dependencies were refreshed, with govulncheck 1.8.0. The library retains its Go 1.26 floor and Go 1.27.1 toolchain; public Go signatures are unchanged.
• The go-systemd v22.6.0 replacement remains necessary for NetBSD compilation.
• Full race suites passed on Go 1.26.8 and 1.27.1, along with lint and LDAP configuration validation. Vulnerability scanning found no reachable or imported vulnerable package; unused OpenPGP code retains module-only GO-2026-5932. The release resolves through the Go proxy and checksum database.

The earlier v3.13.3 policy Deny/NotResource and bounded wildcard fixes remain included. Policies whose clauses were already lost must be recovered from their original source. The module-path migration introduced in v3.13.0 is complete in all four maintained components.

Source changes since v3.13.3 · upstream adoption record.

2.6 - SILO Console 2.4.0 Released

v2.4.0 was published on 2026-09-08 from c103d08e. September 16 follow-up: Console v2.4.1 is the current release. This article records the v2.4.0 behavior and dependencies.

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. The authoritative historical record is its tagged changelog, object-browser guide, and release assets. Later signature/provenance requirements do not retroactively apply to old assets.

2.7 - Silo Console 2.2.0 Release Notes

Version: v2.2.0 · Release commit: 7dc4258a6 · Status: released · Repository: pgsty/silo-console

SILO Console 2.2.0 is a correctness-and-hardening release. It adds one new feature — a strictly bounded text preview for logs and structured text — and spends the rest of its budget making existing surfaces tell the truth: downloads that cannot silently ship a truncated archive, progress bars that cannot fabricate a percentage, permission gates that actually disable what they claim to disable, a user API that no longer entangles status changes with group membership, and database notification forms that emit exactly the connection string the server will store.

Underneath, the dependency stack moves to Go 1.27.0 and onto the maintained SILO forks: 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 is 33 commits touching 176 source files (+8,794/−2,057 lines, not counting the regenerated embedded frontend assets).

Why 2.2.0 and not 2.1.2: the user-visible fixes alone would justify a patch release, but this cycle changes the provider of the shared policy/certificate implementation, crosses an etcd client minor boundary, splits a REST route, and deliberately changes download-failure semantics. Each of those deserves a minor-version line in the compatibility notes below rather than a silent patch.

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

Downloads That Cannot Lie

The whole download path — progress reporting, single objects, folders, archives, byte ranges — was rebuilt around one principle: a download either completes correctly or fails visibly.

Honest progress

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.

Restart honesty

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), dead exports and the unused http-status-codes dependency were removed. The new fast-xml-parser 5.x transitive tree (@nodable/entities, is-unsafe, anynum, fast-xml-builder, path-expression-matcher, xml-naming) was supply-chain-checked during this review: all six packages are published by the fast-xml-parser author’s own account and organization, their installed code is free of execution/network/exfiltration patterns, and the whole tree is development-only — nothing ships in the browser bundle.

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.

Regression Review

Because this release rewrites the download path and re-platforms the shared policy library, the full diff against v2.1.1 was re-reviewed adversarially in five parallel passes (Go API; object browser preview/download; permission gating and service accounts; forms/i18n/session; dependencies/build/CI), each hunting specifically for behavior that worked in 2.1.1 and silently changed.

Verdict: no unintentional regressions found. Every confirmed behavioral difference is one of the deliberate changes documented above. The review did surface two small pre-existing UI-guard defects, now visible because the dead disable-prop was brought back to life with predicates whose argument type was never right:

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

Neither is a 2.2.0 regression — both predicates were entirely dead in 2.1.1 — and in both cases the server still enforces the real rules. They remain documented follow-up items after the release. Two sharp edges are recorded as known limitations rather than defects: the new PostgreSQL DSN parser accepts only canonical key=value syntax when populating structured fields (an unusual-but-libpq-valid DSN shows empty structured fields, and editing a structured field then rebuilds the DSN from those fields), and TestCafe/Playwright coverage asserts UI gating while live-server deny-path coverage remains the integration suites’ job.

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.

Those assets, the tag, and the release page are verified here. This page does not claim a separately distributed container image or detached signatures.

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.8 - 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 does three things:

1. Speaks two languages — 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. Reads the right metrics — the dashboard moves off the MinIO Metrics V2 names onto V3, with explicit handling for the semantics V3 changed underneath it;
3. Stops lying in edge cases — a select-all that matched what a bulk action would delete, placeholders that survive object names containing $&, timestamps that carry a timezone, and empty metrics that read “no data” instead of 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

An adversarial review of the migration produced eight findings, all fixed before release. They share one theme — the difference between zero, no data, and not yet scanned:

• 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 exactly when it matters most.
• 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 was a latent bug in the original English UI, not something i18n introduced; the i18n audit is simply what found it.

A select-all that means what it shows

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 full change set was reviewed and the following gates were run 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 29 intermediate commits were restructured into 20 logical ones by pure tree operations, and the rebuilt tip was verified byte-identical to the pre-rewrite tree. The embedded payload was rebuilt twice from a clean directory and confirmed byte-identical, which is the property the release pipeline’s zero-diff gate depends on. The pre-rewrite history is retained in a backup ref.

The Metrics V3 migration was additionally reviewed adversarially by an independent model, and all eight findings were fixed (see Zero-state semantics); its 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.9 - 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 real runtime data race — is fixed.

Before publication this release went through two independent review passes: a full code review with commit-history restructuring, followed by an adversarial re-verification (exhaustive asset validation, HTTP semantics probing, full routing regression, and smoke tests against the published artifacts themselves).

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 still contain minio or the old console, but they are interface, protocol, or installation compatibility layers — not leftover branding:

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; 2.0.0 does none of that.

A Redesigned Interface

2.0.0 is not a logo swap — the interface was redesigned 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.

Dual Review and Validation Scope

2.0.0 went through two independent review passes before publication. The first pass performed a full code review, fixed the defects described above, restructured 13 intermediate commits into 8 logical ones, and ran Go -race across supported packages, go vet, golangci-lint, govulncheck, frontend type checks, production builds, Prettier, dead-code checks, and the full dependency audit. The second, adversarial pass independently re-ran the core gates and added:

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

The complete pre-rewrite history is preserved in backup refs for rollback.

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.10 - silo-pkg 3.13.0 Released

Follow-up, 2026-09-13: this article preserves the v3.13.0 release-time migration record. All four maintained components have since adopted the own-module path; current pkg is v3.14.0. The “not yet migrated” statements below describe that earlier date; see the current component matrix.

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

Version 3.13.0 is a breaking release with one theme: the module stops claiming upstream’s import path and takes its own. It also retires the pgsty/silo-go fork, which no longer carried anything upstream lacks.

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.
• Not part of this release: the matching silo, silo-console, and mcli migrations.

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.11 - 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 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.
• On SILO remote main: named-policy and service-account policy write integration.
• 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.
• Not part of this release: a SILO server binary, image, package, deployment, or production rollout.

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;
• go mod verify, go vet, git diff --check, and govulncheck with zero reachable vulnerabilities; and
• an implementation-level Claude Opus Max review with a GO verdict and no P0/P1 findings.

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
• a second Claude Opus Max review with a GO verdict; mutation tests proved 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 release environment could not reach proxy.golang.org or sum.golang.org because those connections timed out, so public-proxy observation is not claimed as release evidence. 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

What Is Not Released Here

This article does not claim a new SILO server version, binary, package, container image, deployment, production rollout, Console release, or strict STS rollout. Those remain separate release gates and must be reported separately when completed.

2.12 - 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 useful question is not how dangerous an action sounds in the abstract, but what reaching it adds to a position that already includes all of the data.

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. An independent adversarial review of that release produced a counterexample. Withholding the slash does not merely remove a match — it 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.

The fix is not another special case. 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, and no argument left to get wrong. mybucket* still grants (it matched both all along), mybucket/* is still withheld, and mybucke? is refused exactly as it always was.

Two lessons are worth carrying forward. A correctness fix in an authorization path must never make anything newly allowed — and the only way to know is to test both directions, because the reasoning felt airtight in both cases where it wasn’t. And when a security property is load-bearing, build it out of an operation that cannot violate it rather than out of a case analysis believed to be complete.

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.13 - Silo 20260903 Released

Status on 2026-09-13: this remains the latest published Server; its dependencies have not changed. Later security, storage and dependency fixes are on main, including the unreleased SN-2026-011 fix. New standalone mcli/pkg releases do not replace this artifact’s contents; see the component matrix.

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. Its main theme is not a new delivery surface but a tighter set of 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 deliberately uses 20260806 as its only release baseline. Intermediate component builds remain identifiable in their source repositories, but the public documentation below consolidates the complete server, Console, shared-package, and client result delivered on 2026-09-03.

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. The standalone Console release and the server embedding remain separately verifiable artifacts.

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.

The zero-byte and attributes fixes remove two independent places where “no data was decrypted” had accidentally been treated as “the key was authenticated.” The new rule is explicit: access to SSE-C metadata or ciphertext requires a successfully unsealed object key, unless the request has already crossed the authorized replica boundary.

The CopyObject state matrix and live interoperability evidence are preserved in CopyObject SSE-C, checksum, and response correctness.

Listing and federation

• ListObjects shortcuts now return NoSuchBucket for a missing bucket even when a prefix selects an early-return path (#32, PR #37).
• Federated UploadPartCopy preserves the backend checksum in the public response (#72).
• Site-replication status counts metadata operations per site instead of multiplying a group-wide result, and validates CORS as an independent configuration field.

The missing-bucket shortcut is documented in ListObjects must prove the bucket before it optimizes.

Per-bucket CORS and request trust

Bucket CORS was implemented end to end rather than as a handler-only shim:

1. the S3 XML type and rule matcher enforce the protocol grammar and multi-rule preflight behavior;
2. bucket metadata stores the raw configuration and returns it byte-for-byte on GET ?cors;
3. the outer middleware uses the bucket policy when present and the global origin setting only as fallback;
4. site replication carries CORS in its own tombstone-aware last-writer-wins register;
5. pre-authentication lookup never loads metadata or creates cache entries;
6. startup, a known bucket-metadata load failure, deletion, refresh, and on-demand reload all update the fail-closed state explicitly.

The load-failure state is intentionally retained. A pre-signed URL authenticates itself without consulting bucket policy; if the server forgets that a real bucket’s CORS document failed to load, falling back to a permissive global policy would discard the only browser-origin boundary around that otherwise authorized request.

Replication-request hardening shares the same principle. The server authenticates the original request first because internal headers may be covered by SigV4, derives one private trust decision from the authenticated identity and permission, and only then sanitizes an untrusted request clone. The clone shares the original trailer map so streaming checksums remain visible. Snowball workers derive trust per entry rather than inheriting a request-wide privilege bit.

The full design and rejected alternatives are preserved in No I/O Before Auth, No Privilege From Headers.

Bucket metadata and Object Lock

Bucket configuration is stored as one .metadata.bin record but was previously updated through independent locks for policy, lifecycle, encryption, tags, quota, replication, Object Lock, and CORS. Two valid read-modify-write operations could therefore each succeed while the later save silently discarded the earlier field.

This release introduces one bounded metadata.lock transaction around every whole-record mutation. The same lock covers:

• normal configuration saves and deletes;
• legacy metadata migration and import;
• bucket creation, ForceCreate, and site adoption;
• healing and inconsistent-version repair;
• replication receive paths that merge changed fields.

The implementation does not turn the metadata system into a generic transaction framework. It keeps the existing record and parsers, centralizes only the serialization boundary, and narrows replicated updates to fields that actually changed.

Object Lock receives a second invariant. Once a valid lock configuration parses as enabled, versioning is normalized to a plain Enabled document; prefix exclusion and suspended states cannot survive. The decision is based on the parsed configuration, not byte equality with the smallest possible XML document, so a valid Default Retention rule cannot bypass it. Update, read-back, and disk-reload tests cover both malformed prior versioning shapes.

IAM, policy, and configuration behavior

• Explicit version deletion follows AWS s3:DeleteObjectVersion authorization while replication deletes retain s3:ReplicateDelete.
• SetUserStatus and SetGroupStatus authorize the requested target state instead of always checking the enable action.
• New and updated named policies and service-account policies reject bare S3, S3 Tables, and KMS ARN namespace prefixes, their historical serialized forms, and statements that combine Resource with NotResource. Stored policies continue to load.
• Enabled legacy PostgreSQL or MySQL notification targets must supply a connection string. Startup now fails with a credential-free diagnostic instead of silently discarding all targets.
• MINIO_CONFIG_ENV_FILE parsing preserves named targets, quoted values, and supported shell-like assignments without evaluating the file as shell code.

These changes are compatibility tightenings, not format migrations. Review the upgrade checklist before deploying.

Detailed records cover target-state user/group authorization, safe configuration environment-file parsing, and fail-fast legacy database notification migration.

Components

The 20260903 dependency and companion-release line is pinned as follows:

• Go 1.27.1
• minio-go/v7: upstream-compatible pseudo-version ending in 0e78d3f18efe; the temporary silo-go fork is retired from the server graph
• madmin-go/v3: v3.0.110
• silo-pkg/v3: v3.13.2, under its own github.com/pgsty/silo-pkg/v3 module path
• embedded Console: v2.3.0, including the trusted-proxy, TLS, redaction, and WebSocket security work
• bundled mcli: RELEASE.2026-09-03T07-13-05Z, with the mc compatibility alias preserved
• Helm chart: 7.0.2; use the published server image pgsty/silo:RELEASE.2026-09-03T13-18-01Z and the mcli image pgsty/mc:RELEASE.2026-09-03T07-13-05Z

Tagged-source Helm note: the signed Server tag retains the provisional RELEASE.2026-09-03T00-00-00Z value in helm/silo. Post-release commit 4c164907f corrects the current main chart to the published tag. If you render Chart 7.0.2 directly from the tagged source archive, set image.tag=RELEASE.2026-09-03T13-18-01Z explicitly; binary and package artifacts are unaffected.

The server deliberately preserves the MinIO-compatible Go module and wire identifiers. Replacing an import target does not rename the public S3/Admin API, MINIO_* configuration, x-minio-* headers, /minio/* routes, or on-disk metadata.

Engineering cleanup

The final release pass removed complexity where it did not protect a compatibility or correctness boundary:

• removed dead encryption helpers, obsolete handler paths, and unused event-target functions;
• replaced a source-level exported-symbol inventory with the smaller served-route compatibility baseline;
• removed the wait_pipe lint exclusion and migrated to gomodguard_v2;
• consolidated CORS load-failure lifecycle changes behind two helpers instead of open-coding set operations in six paths;
• narrowed site-replication imports to changed metadata fields;
• gave dynamic-timeout tests their own random source so parallel tests cannot mutate a package-global seed;
• retained the shared metadata lock, CORS tombstones, two-level replication trust, and adversarial tests because each protects a reproduced failure rather than a hypothetical abstraction.

The complete adversarial review, including the fixes found after the first “ready” claim, is recorded in SILO Server 20260903 Pre-release Review.

Upgrade checklist

Read Upgrading from RELEASE.2026-08-06 before changing production. At minimum:

1. grant s3:DeleteObjectVersion to identities that intentionally delete explicit versions; add its Deny next to any Deny s3:DeleteObject intended to prevent permanent deletion;
2. split custom admin grants for enable and disable operations;
3. correct bare ARN prefixes before re-submitting policies;
4. add connection strings to enabled legacy PostgreSQL/MySQL notification targets;
5. verify applications that explicitly choose checksum algorithms or types;
6. upgrade every member of a site-replication group before creating or changing per-bucket CORS;
7. snapshot CORS configuration before rollback, because 20260806 does not understand it;
8. switch every node of a distributed cluster to the same binary in one maintenance operation; mixed Silo binaries do not form a cluster.

The on-disk object and erasure formats are unchanged. This does not make a mixed-version cluster supported.

Known issues and explicit deferrals

These items are not fixed by this release:

• Conditional delete (#10, PR #12). DeleteObject ignores HTTP If-Match and DeleteObjects ignores each <Object><ETag>. Both delete unconditionally. A reviewed single-object repair exists outside this release, but batch semantics and the original PR are incomplete; shipping a partial condition contract would be riskier than the documented deferral.
• Non-CORS multi-site configuration deletion (#77). A peer can restore a policy, SSE, tag, or quota configuration deleted on another site. Single-site deployments are unaffected. CORS is not affected because it uses a tombstone-aware register. Deployments relying on these replicated deletions must verify every site.
• ListMultipartUploads filters (#79). prefix behaves like an exact key match, while max-uploads, key-marker, and delimiter are not fully honored; see the conformance analysis.
• Legacy federation CopyObject (#99, #100). The legacy federated backend can ignore a requested checksum algorithm and rejects inline source objects. Deployments not using that backend are unaffected.
• Mixed-version site replication. A 20260806 peer accepts but ignores bucket CORS and continues reporting a mismatch. Do not configure CORS until all sites are upgraded.
• Rollback of bucket CORS. 20260806 drops the unknown CORS field if it rewrites the bucket record. Export the configuration first and recreate it after upgrading again.

Open enhancement work such as ILM relocation (PR #60), broader SSE support (#61), operator discovery (#30), NATS target hot reload (#40), and Renovate (#20) is outside this release’s production-safety boundary.

Verification and evidence boundary

The complete local acceptance was run on ebac0ca73bbf251b070bb6df4d8005015841f901:

• full cmd and internal test suites;
• go test -race ./cmd, passing in 365.448 seconds;
• lint with 0 issues, the rebrand/compatibility guard, generated-file checks, and govulncheck;
• make verify across FS, erasure, distributed erasure, erasure sets, multi-pool, and IPv6 multi-pool: 174 PASS / 0 FAIL.

One subsequent one-line fix, 84e1580a4, clears the CORS load-failure bit after a successful on-demand GetConfig reload. Later dependency work moves the toolchain to Go 1.27.1 and x/crypto 0.56.0. On exact release source 9b11dc9469e650815b775cb47b039610644f5da4, git diff --check, full cmd and internal tests, the complete cmd race suite, rebrand and generated-file guards, lint, govulncheck, and remote Go CI, VulnCheck, Test Release, and Release workflows pass.

The final functional acceptance used four Ubuntu 24.04 arm64 VMs with four XFS data disks each. It covered a coordinated 20260806 → 20260903 upgrade, rollback, and second upgrade; the complete mcli functional script over TLS; 1,004-object upload/download checksum comparison; one-node and quorum-loss behavior; single-drive reconstruction; and two-site replication of objects, versions, CORS, tags, quota, ILM, Object Lock, IAM, delete markers, and offline catch-up. The cluster finished with all 16 drives online and no unrecovered data mismatch.

Container publication exposed one delivery-only pin error after the binary/package Release was public: the first Docker workflow stopped before pushing any image because the tagged Dockerfile selected mcli 20260903 but retained the two 20260901 archive digests. Commits ce2326c94 and 9936a69d8 corrected those pins and added a narrow recovery mode that resolves them from the immutable, attested mcli checksum manifest. Recovery run 33847571968 then built, ran, SBOM-attested, and published both architectures from the original Server release archives. The classic release/latest manifest is sha256:b616a0cf8cb281e7e6bb3c9b1fb53875b4016a2878223925541c18f82d6c5ca3; distroless is sha256:2711cdc5bce0ada353a4871dcda60f48f46414fdd69a45c36c71f6b7ebe1aead.

Delivery remains independently checkable rather than inferred from those source tests. The published server GitHub release identifies the exact tagged source and verified archives, packages, checksums, SBOMs, and provenance; its classic and distroless images publish matching amd64/arm64 manifests. The separately published mcli release is immutable, contains 19 verified assets, and publishes matching amd64/arm64 release and latest images. Shared package v3.13.2 and Console v2.3.0 retain their own release evidence.

Resolved issue ledger

The tracker was reconciled during release preparation. Core issues are closed; deliberately excluded work remains in its own open issue:

Selected changes

• 1c9a2431f through 13e6458d9: implement per-bucket CORS and site replication
• 938603458 through 04b097fd9, plus Snowball follow-ups: authenticate replication semantics and remove pre-authentication metadata I/O
• f9f9fa6c9 through 32a1b81e4: reproduce and serialize cross-type bucket metadata updates
• 3b5de82f5, 21646eebd: enforce Object Lock’s versioning invariant, including retention-rule documents
• f8b598f1d through d2d47a41f: align explicit-version delete authorization
• b73581b05, 474cd5801, 74c97d005: authenticate SSE-C zero-byte and attributes reads
• 7fea6d5a5, 5d152416d, 7e079ff05, d28885d0e: align multipart checksum behavior
• c0e715977, e73436c99, ffb70eb37: repair CopyObject transforms, checksums, and SSE-C rotation
• 84e1580a4: clear the load-failure guard after an on-demand metadata reload succeeds

Acknowledgments

This release incorporates reports and proposed fixes from community contributors as well as the fork’s security and compatibility audit. In particular, the checksum, missing-bucket listing, and explicit-version authorization work started from public issues and pull requests. The release’s final shape also reflects adversarial review: findings were reproduced before repair, inherited limitations were separated from release regressions, and validation claims were rerun against the tree they describe.

The complete authorship record remains in CONTRIBUTORS.md.

2.14 - Explicit Version Deletes Now Require DeleteObjectVersion

Release status: this change is implemented in pgsty/silo#104, tracking issue #58. Publishing this note does not by itself mean that a server release, package, image, or deployment contains the change.

SILO now maps object-delete authorization to the operation the request will actually perform:

Previously, SILO required s3:DeleteObject for every case and used s3:DeleteObjectVersion only as an explicit-deny check. A principal holding only DeleteObject could therefore permanently remove a named historical version. Conversely, a least-privilege purge principal holding only DeleteObjectVersion could not perform the operation it was intended for.

After this change, a DeleteObject-only principal can still perform an unversioned delete or create a delete marker, but receives AccessDenied for a named UUID or null version. A DeleteObjectVersion-only principal can remove the named version but cannot create a delete marker. Explicit denies and s3:versionid conditions retain normal policy precedence. Multi-delete uses each entry’s VersionId; a query-level decoy cannot change another entry’s condition value.

Replication compatibility

Bucket and site replication target policies do not need to add s3:DeleteObjectVersion. An authenticated request earns replication delete trust through an exact internal marker and s3:ReplicateDelete; the receiver then preserves the deployed s3:DeleteObject + s3:ReplicateDelete contract. An explicit deny on s3:DeleteObjectVersion continues to block a replicated version purge.

This distinction prevents an upgraded target from silently rejecting permanent delete replication and also avoids granting new delete capability to a ReplicateDelete-only credential. A real two-site regression used a target user with the documented minimal policy and no DeleteObjectVersion; both a permanent version delete and a delete marker converged successfully.

Upgrade impact

• Review user, service-account, OPA, and external authorization policies that currently grant only s3:DeleteObject but perform mc rm --version-id, mc rm --versions, Console delete-all-versions, or SDK deletes with versionId.
• External authorization plugins now see one s3:DeleteObjectVersion decision for an ordinary named-version delete instead of the former deny-only check followed by s3:DeleteObject.
• X-Minio-Force-Delete prefix cleanup remains gated by s3:DeleteObject; it is not an explicit-version S3 request.
• There is no wire or storage-format migration. Rolling back restores the old authorization mapping but does not alter stored objects or metadata.

See Object Deletion for the operator-facing permission matrix.

2.15 - mcli 20260903 Released

Published: 2026-09-03 · Version: RELEASE.2026-09-03T07-13-05Z · Source: a2ef95c0

Twenty-eight days after mcli 20260806, this release carries everything the client accumulated since. The toolchain moves to Go 1.27.1 and the shared dependency stack is aligned with the SILO family, with silo-pkg imported under its own module path so go.mod says what the binary is built from. The first genuinely new command since the fork arrives — mcli checksum verify, a read-only audit of stored S3 additional checksums against the bytes an endpoint actually returns. The panic that made --json admin prometheus metrics unusable is fixed, as is the response double-close that could panic after mcli sql had printed valid rows. And every path that can print a credential — --debug traces, admin trace, error messages, JSON error documents, checksum reports — was rewritten fail-closed after adversarial review. The release process changed as much as the code: artifacts come from a GPG-signed tag at the exact tip of main with green CI for that commit, ship LICENSE, NOTICE, and a generated CREDITS in every format, carry Sigstore build provenance, and land in an immutable GitHub release.

The release was built from a2ef95c0, the merge of pgsty/mc#27: 58 reachable commits, 50 of them non-merge commits, across 262 files (+12,742 / −6,566 lines) since RELEASE.2026-08-06T00-00-00Z. The intermediate 20260901 build remains available on GitHub, but this page treats 20260806 as the public documentation baseline and records the complete 20260903 result.

Major Changes

• Go 1.27.1 across the module, container build stage, Linux/macOS/Windows CI, cross-builds, tidy checks, and vulnerability analysis. The Go-maintained module family is current: x/net 0.58.0, x/sys 0.47.0, x/term 0.45.0, x/text 0.41.0, x/crypto 0.56.0, x/mod 0.40.0, x/sync 0.22.0, and x/tools 0.49.0. golangci-lint stays outside the product module graph and is installed independently at the pinned v2.13.1.
• The SILO package under its own module path. go.mod now requires github.com/pgsty/silo-pkg/v3 v3.13.2 directly. The client’s policy validation depends on helpers that exist only there — policy.ParseConfigStrict and policy.Resource.IsBareARN — and a replace of upstream minio/pkg would not be inherited by projects consuming this module (pgsty/mc#12), so the requirement is declared honestly. Upstream minio/pkg survives only as an indirect dependency of colorjson, held at v3.6.1 by the dependency-floor check, and gomodguard blocks the upstream import path from returning. minio-go moves from v7.0.99 to the latest upstream minio/minio-go master commit, represented by v7.3.1-0.20260828014306-0e78d3f18efe; the interim pgsty/silo-go fork is retired. The final refresh includes etcd 3.7.1, go-pretty 6.8.3, klauspost/compress 1.20.0, Prometheus client/common/procfs 1.24.1/0.71.0/0.22.0, grpc-gateway 2.30.0, gRPC 1.83.2, Protobuf 1.36.12, and JWX 3.2.0. go-systemd deliberately stays at 22.6.0 through SILO’s portability pin — 22.7.0 does not compile on NetBSD.
• Runtime version floors are guarded. A first dependency pass let the removal of development tools silently lower a dozen runtime selections — among them shoenig/go-m1cpu, whose older releases crash during initialization on newer Apple Silicon when CGO is enabled — and was rejected. buildscripts/check-dependency-floors now compares every requirement in go.mod against the previous RELEASE.* tag and fails the build on a regression; the only permitted exception is the go-systemd pin.
• mcli checksum verify (design). Verifies stored S3 additional checksums — CRC32, CRC32C, CRC64NVME, SHA1, SHA256, of type FULL_OBJECT — against the logical object bytes returned by the object API, for one object, a prefix with --recursive, all versions with --versions or an exact --version-id, or a JSON Lines candidate manifest. It reads with If-Match on unversioned objects and re-stats afterwards, so a write that races the verification is reported as UNKNOWN_OBJECT_CHANGED rather than as a mismatch. Each object yields one of MATCH, MISMATCH, NO_CHECKSUM, WOULD_VERIFY (dry run), one of ten UNKNOWN_* classifications, or one of three SKIPPED_* results; the summary carries objects, a verified count (MATCH + MISMATCH, the only results that actually recomputed a checksum), per-status counts and incomplete. --fail-on accepts mismatch, unknown, no-checksum (fails when any object lacks a checksum or when nothing was verified at all), any (default: mismatches, unknowns, and objects skipped by --max-size), or none. --report writes the same records to a new 0600 JSON Lines file. Results go to stdout whether or not stdout is a terminal, and with --json they are compact JSON Lines outside a terminal — the non-TTY silence reported as pgsty/mc#5 is fixed. Dry runs, --max-workers, --max-size, time filters, and SSE-C through --enc-c are supported. The command is verified against a real SILO server in CI.
• Credential redaction, fail-closed. Three rounds of adversarial review by Codex showed that the original redaction — and its first two rewrites — recognized the shapes it expected and let everything else through: access keys containing a slash, an Authorization value whose first field is empty so the second one hides, non-hex signatures, secrets tucked into the credential scope or SignedHeaders, Proxy-Authorization, cookies, X-Api-Key, response trailers, a redirect Location with userinfo, a server that reflects request headers into an error body, a JSON-escaped secret inside --json error output, a short token that appears twice. The final design has three rules and no exceptions. An Authorization-class value keeps only its scheme. A header whose name looks like a secret, or that the caller supplied through --custom-header, is redacted without inspecting its content. Text the client did not generate itself — response bodies, server error messages, trace notes — is scanned for credential shapes and then scrubbed of every secret literal the process has learned. That last layer is backed by a process-wide secret registry: alias secret keys and session tokens, MC_HOST_* values, SSE-C keys in every encoding, tier and service-principal secrets, GCS credential files, LDAP passwords and the STS credentials they return, SUBNET tokens, --secret-key/--account-key/--api-key flags, and secret-bearing key=value arguments are registered as they are read, before validation and before any network call. Occurrences are collected as intervals and merged before replacement; JSON error documents are scrubbed on the decoded value tree, string leaves only, so keys and compact non-terminal formatting survive. Forty-odd adversarial cases, a black-box test that runs the real client against an endpoint that reflects everything it receives, and live captures against a SILO server pin the result.
• admin trace redaction. Server-supplied header maps for other clients’ requests take a path the S3 tracer never touched. Both the human-readable and the JSON rendering, in the default and the verbose form, are now produced from redacted copies — the event is shared between them and never mutated. Query strings (a presigned URL’s signature, a session token in the first parameter), bodies, error text and annotations are scrubbed with the event’s own header values, so a token another client sent cannot reach privileged trace output. Headers are redacted by name: a --custom-header another client sent under a name that does not look like a secret is shown as the server saw it.

Fixes

• JSON metrics no longer panic. mcli --json admin prometheus metrics failed for both the v2 and v3 metrics APIs with panic: Invalid name validation scheme requested: unset in the 20260806 client. madmin-go built the zero value of the Prometheus text parser, which prometheus/common 0.66 and newer reject. The client now constructs the parser with UTF-8 validation, returns ordinary parse errors instead of panicking, and emits families in name order.
• pipe with empty input performs a regular PUT; the one-part multipart upload it used to issue for zero bytes was needless and produced a multipart-style ETag.
• RPM payload validation aligned with the signing script, so an RPM whose contents do not match the release metadata is refused before it is signed.
• sql no longer panics after printing its rows. The SDK’s select reader closes the HTTP response itself on every terminal event, and the client closed it a second time; on a zstd-compressed response the two drains raced and about two in five queries against a SILO server ended in panic: invalid memory address with exit status 2 after the rows had already been written (pgsty/mc#23). The client now cancels the request and drains the result pipe instead of closing the response again; 820 consecutive queries on a live server ran without a panic where the previous client failed 21 of 50.

Hardening

• Operator-produced files are no longer world-readable. support diag warned that its archive may contain sensitive environment information and then wrote it 0666; the shared moveFile helper relaxed every 0600 temporary file to 0644 on its way to the final name, and a 0644 left by an earlier client was carried into the rotated backup even when source permissions were preserved. Every support artifact is now created 0600 and chmodded before the first byte is written.
• Test_FullSuite fails on panic. The functional suite recovered from panics to run cleanup and then reported success; a panic anywhere in the suite, including in the binary build, was invisible to CI.
• A leftover play/ alias in the new command’s help — the only file in the repository still advertising MinIO’s operated demo alias — is replaced, and the brand gate now rejects bare aliases in command examples, not only hostnames.
• AGPL notices completed on six fork-authored files that carried only the first half of the license text.

Engineering and Delivery

• Third-party notices in every artifact. CREDITS is generated by buildscripts/gen-credits.sh from the union of the runtime modules linked into all six GoReleaser targets and is compared in CI so a dependency change cannot leave it stale. LICENSE, NOTICE, and CREDITS ship in the GoReleaser archives, the DEB/RPM/APK packages, and every container image under /licenses/.
• CI runs on main. Go and Crosscompile ran only on pull requests, so the merge commit — the one that gets tagged — was never tested; both now run on every push to main. Their concurrency group was keyed on github.head_ref, which is empty outside pull requests, so every manual run cancelled every other; it is now keyed on the pull request number with the ref as fallback. VulnCheck also runs weekly, because a fork of an archived upstream can go weeks without a commit. The functional suite in CI now targets SILO RELEASE.2026-08-06T00-00-00Z.
• Release only from signed tags. The artifact workflow has no manual trigger; artifacts come from a pushed RELEASE.* tag, and the event SHA, the commit the tag points to, and the checkout must all agree. verify-release-tag.sh requires an annotated tag with a valid OpenPGP signature from the expected key — fingerprint and key location come from repository variables rather than from the tree the tag points at, and the imported key must match the expected fingerprint. check-release-commit.sh requires the tagged commit to be the exact tip of origin/main and demands a successful push-to-main run of four workflows for that SHA, matched by workflow file path; pull request and manual runs are not evidence. check-release-state.sh (pgsty/mc#6) runs serially per tag, replaces exactly one existing Draft from scratch, refuses a published release, and re-checks for a single Draft before packages are uploaded. Every one of these decisions lives in a shell script with fixture coverage; the fake gh in the tests pins both the verdicts and the arguments passed, verbatim.
• Provenance and immutability. Archives, checksums, DEB and APK packages carry Sigstore build provenance (gh attestation verify <file> --repo pgsty/mc). RPMs are excluded on purpose: sign-release-rpms.sh rewrites their bytes with a detached GPG signature from key 9592A7BC7A682E7333376E09E7935D8DB9BD8B20 while the release is still a Draft, and an attestation made earlier would name a digest no published RPM has. GitHub releases are immutable once published; fixing an asset means a new tag. The pgsty/mc container image is built only from attested archives, after gh attestation verify binds each one to release.yml@refs/tags/<tag>, the release commit digest, GitHub-hosted runners, its own filename and its SHA-256; the unpacked binary’s ELF machine type must match the archive’s architecture; each per-architecture image is pulled, run, and checked for the tag before the manifest is assembled, and latest is written only from the two-architecture manifest. The UBI base image is pinned by digest and kept current by Dependabot.
• Repository governance matches a single-maintainer project. Direct pushes to main are allowed; the stale pull-request ruleset and its exact-name status-check coupling were removed after this release. Release integrity does not depend on that branch rule: the artifact gate still requires successful push-to-main Go, Crosscompile, VulnCheck, and Test Release runs for the exact tagged commit. RELEASE.* tags remain administrator-created and immutable; secret scanning, push protection, Dependabot alerts, and security updates remain enabled.
• Verified before and after tagging. On exact source a2ef95c035d9ae7cc01469a63926900f1786f9e2, tidy/verify, dependency floors, unit tests, the full race suite, lint, actionlint, source-aware govulncheck, and nine standard cross-builds passed. Claude Fable 5.1 at xhigh independently returned GO with no blocking findings after a clean-cache Go proxy/sumdb build, 172 functional checks against a temporary SILO server, a 47-command black-box comparison with the published 20260901 binary, and seven additional cross targets. All four exact-SHA main workflows and both publication workflows passed. The immutable public release contains 19 assets; archives and sidecars were checksum-verified, all 11 attested subjects were bound to the tag and source commit, both RPMs were GPG-verified, and the pgsty/mc release and latest images were independently confirmed as matching amd64/arm64 manifests. The source scan reports no reachable vulnerability.

Compatibility

The full --help tree of this release was diffed against the 20260806 binary: the only difference is the new checksum command. Side by side on the same server, head, cat, get, cp, mirror, find, share, sql, stat, and ls produce identical output and JSON field sets; twenty real-world policy shapes are accepted or rejected identically except for bare ARNs; admin policy info --json is byte-identical. The mc command name and the mcli package name; the ~/.mc / ~/.mcli configuration directories; the github.com/minio/mc module path and all import paths; MC_* environment variables; protocol headers (x-minio-*) and the minio-go user-agent prefix; the minio tier type; the .part.minio transfer suffix; the minio-job scrape job name; and the package formats, asset naming, and YYYYMMDDHHMMSS.0.0 version scheme are unchanged. The client remains compatible with MinIO servers and other S3-compatible endpoints. Projects that consume this module as a Go dependency now resolve github.com/pgsty/silo-pkg/v3 directly and need no replace of their own for it.

Related Commits

• 98a8b0f: build: prepare the 20260903 dependency release
• 6686b64: chore(deps): align the SILO Go dependency stack
• 423490d: fix: stop JSON metrics from panicking
• 14b05e6: build: generate and package third-party notices
• e938cea: fix: align RPM payload signing validation
• 8158605: release: adopt Silo Go SDK v7.3.1
• d6ba236: ci: allow manual release workflow runs
• b6b2655: ci: release an existing tag on dispatch
• 70a2950: fix: preserve embeddable pkg compatibility
• aa07b1c: feat: add read-only object checksum verification
• 1b39423: fix: preserve checksum output in pipelines
• a31a42b: docs: record checksum verify output contract
• 2121081: fix: validate policy writes strictly
• 712bf3a: fix: use regular PUT for empty pipe input
• 9a3805d: ci: make release retries tag-idempotent
• 7bc9843: test: make report permissions portable
• 2d5abc2: chore: complete the AGPL notice on fork-authored files
• f5c5dc9: build: import the SILO package under its own module path
• a8e7eb4: ci: test main on push and stop dispatch runs cancelling each other
• b75d28b: fix: stop checksum verify help from advertising the play alias
• c05da7b: chore: drop configuration for bots that are not installed
• a29b455: fix: stop –debug from printing credentials
• 08244df: fix: keep secrets out of error messages and traces
• 30a7ea0: fix: stop writing support artifacts world-readable
• 14bd724: test: fail the full suite when it panics
• 4abbb3a: feat: expose how much checksum verify actually verified
• f484d0d: ci: make a release prove its commit, and pin what it builds from
• 2c33a4e: chore: ignore the local consumer-module review scratch directory
• bdc742a: fix: close the remaining –debug credential leaks
• 3998392: fix: withhold SSE-C keys and credential URLs the parser rejects
• c1358c4: fix: force 0600 on rotated support artifacts too
• 45e5144: fix: fail –fail-on no-checksum when nothing was verified
• 3674933: ci: make the release gate provable and its claims true
• 8b7b2e9: test: exercise checksum verify against a real server
• 4b36b0a: fix: make credential redaction fail-closed and scrub final output
• a6c14da: ci: verify build provenance before repackaging archives into images
• 915cfd9: fix: reject a malformed app-level global flag instead of ignoring it
• 81e2767: fix: rebuild SigV4 traces from known fields and widen secret scrubbing
• 625713c: fix: keep only the scheme of a signed header and scrub JSON structurally
• ec12b64: fix: redact admin trace output and register every credential ingress
• 1445e88: ci: release only from a signed tag at the tip of main, verify exact provenance
• f188939: fix: close final credential and release verification gaps
• f5b88dd: fix: redact the default admin trace and stop the shape sweep mangling prose
• 59989f8: fix: let svcacct set clear a policy again, report bad global flags once
• d38412a: fix: classify an SSE-C refusal with a key as a read error, keep policy and size messages clear
• b291b53: fix: register a URL password as written, keep listing parameters visible in traces
• 9dfca8f: test: drive the SSE-C refusal classification through the verify path
• 76b2e89: fix: keep an unquoted DSN password whole and match auth schemes case-insensitively
• 328efee: fix: register the password before the first separator of an unquoted DSN payload too
• 7057705: fix: avoid double-closing S3 Select responses

2.16 - mcli 20260806 Released

Published: 2026-08-06 · Version: RELEASE.2026-08-06T00-00-00Z

Two days after mcli 20260804, this release completes the client’s transition to the Silo identity. It is deliberately a pure rebranding and lockdown release: --version and --help now present the Silo client, every remaining path to MinIO’s SUBNET service is disabled at build time, the embedded vendor encryption key is removed from the diagnostics tooling, and the contribution policy moves to no-CLA with a mandatory DCO sign-off. There are no dependency changes and no protocol changes in this cycle — go.mod is byte-for-byte identical to 20260804 — so the regression surface is confined to text, command gating, and CI.

Major Changes

• Silo identity across the CLI: the client introduces itself as “Silo client for object storage and filesystems”. Roughly 220 help texts were reworked: usage lines that refer to the managed server now say “Silo/MinIO server”, example aliases moved from myminio/play to mysilo, example LDAP DNs moved to dc=example,dc=com, and example tier names to SILOTIER-*. Factual references stay factual: the minio tier type, protocol headers, and third-party interop mentions are untouched.
• SUBNET disabled at build time: connectivity is compiled out behind a single guard, and the one HTTP choke point that every SUBNET request funnels through refuses with the stable error above. Command entry points gate early, diagnostics force local mode, and the AGPL license notice shown by mcli license info no longer carries a commercial-subscription pitch. A dedicated regression suite (cmd/subnet-disabled_test.go) pins all of this, so an upstream merge cannot silently reconnect anything.
• Governance — no CLA, DCO required: contributions are accepted inbound=outbound under AGPL-3.0-or-later; contributors keep their copyright, and the maintainers collect no rights beyond the project license. Every commit must carry a Signed-off-by trailer, enforced by a new CI workflow that matches the trailer against the commit author’s email and exempts only GitHub-issued bot addresses. CONTRIBUTING.md, the PR template, and both READMEs document the policy, and the code-of-conduct contact now points at the fork’s maintainer.
• Dual copyright attribution: runtime output and help now credit both lineages — Copyright (c) 2015-2025 MinIO, Inc. and Copyright (c) 2025-2026 PGSTY — with source builds computing the end year dynamically. NOTICE states the fork relationship, and the non-affiliation with MinIO, Inc., explicitly.
• Release line renamed to main: workflow branch filters, documentation, and contributor instructions now target main; the legacy master references are gone.

Hardening

• Vendor encryption key removed: mcli support inspect used to fall back to encrypting its output with an embedded MinIO RSA public key whenever no key was supplied — producing archives only the vendor could decrypt. The embedded key is gone: inspect now relies on the server-generated per-request key that is printed to the caller (or an operator-supplied key), and any encrypted-upload path with no configured recipient fails closed instead of silently borrowing a third-party key. Diagnostic output an operator produces is now always decryptable by that operator.
• Brand-policy gate: buildscripts/check-branding.sh runs in make verifiers and in CI. It fails the build if MinIO-operated endpoints, commercial upsell URLs, the upstream product identity, or any embedded MII… public key reappear in the command tree — while explicitly allowlisting the preserved compatibility identifiers (environment variables, protocol headers, module path, legacy-migration defaults, and original copyright headers).

Engineering and Delivery

• CI moved to the Node 24 Actions line: actions/checkout v7, actions/setup-go v7, goreleaser-action v7, and the Docker action family — all still pinned to commit SHAs, with dependabot keeping the pins current.
• Functional tests run against controlled servers only: the suite defaults to a local server (localhost:9000) instead of MinIO’s public demo cluster, and CI downloads the pinned SILO server release RELEASE.2026-08-04T00-00-00Z from pgsty/silo, verified by SHA-256, before running the suite.
• Zero dependency changes: no module updates this cycle; the 20260804 security baseline (Go 1.26.5, zero known reachable vulnerabilities) carries over unchanged.
• Audited before tagging: the release was gated by an independent adversarial review — a full read of the 245-file diff, brand/compatibility grep sweeps, call-graph verification that no command or flag combination can reach subnet.min.io / play.min.io / dl.min.io, and smoke tests confirming every disabled path returns its stable error with exit status 1.

Compatibility

Everything scripts and integrations depend on is deliberately unchanged: the mc command name and the mcli package/binary name; the ~/.mc / ~/.mcli configuration directories (derived from the invoked name); the github.com/minio/mc module path and all import paths; MC_* environment variables; protocol headers (x-minio-*) and the minio-go SDK user-agent prefix; the minio tier type; the .part.minio transfer suffix; the minio-job Prometheus scrape job name; and the package formats, asset naming, and YYYYMMDDHHMMSS.0.0 version scheme. The client remains fully compatible with MinIO servers and other S3-compatible endpoints.

Related Commits

• 8a883ca: ci: move the branch filters to main and fetch the server from pgsty/silo
• 8c304dd: ci: move the pinned actions onto the Node 24 runtime
• 02b1c11: docs: name the release line main, not master
• 810bbd2: ci: pin the functional-test server to a release whose watch API works
• d145647: fix: disable SUBNET connectivity and licensing upsell paths
• 5061c4f: rebrand: adopt Silo identity in CLI help and examples
• c7f7706: docs: align governance files and package metadata with the fork
• 65c71b2: test: default functional tests to a local server and add brand gate
• c62a64d: fix: credit both MinIO and PGSTY in copyright notices
• d205f88: docs: adopt no-CLA plus DCO contribution policy
• 95326ce: docs: add related-projects table and polish contribution wording
• d2c0db7: fix: remove the vendor encryption key and close the proxy-set path
• 0c6704d: fix: repair a link and help text damaged by the brand sweep

2.17 - Silo 20260806 Released

Version: RELEASE.2026-08-06T00-00-00Z · Commit: 3be10fcc1a44f6620ded0bd303461f9d688cca23

SILO 20260806 is the first release published under the Silo name. The previous release, 20260804, was the last one delivered as pgsty/minio; this release completes the cutover to github.com/pgsty/silo and renames every delivery surface — binary, packages, container images, systemd unit, Helm chart — while deliberately preserving every wire and configuration surface a MinIO deployment depends on. On top of the rename it adds native health checking (silo healthcheck), a single-binary distroless container image pilot, complete license-compliance materials in every artifact, and a release pipeline gated on compatibility snapshots and build provenance.

The release covers 28 commits after RELEASE.2026-08-04T00-00-00Z, changing 396 files with 27,188 insertions and 19,561 deletions. It passed a six-phase pre-release acceptance, including a real four-node TLS cluster migration from MinIO to Silo — with byte-verified data integrity, maintenance-gated rolling restarts, fault injection, and a full rollback rehearsal.

Highlights

• The rebrand is complete, and compatibility is the contract. Repository, binary (/usr/bin/silo), packages (silo rpm/deb/apk), images (docker.io/pgsty/silo), and service (silo.service) are renamed; the S3 and admin APIs, /minio/* routes, MINIO_* environment variables, x-minio-* headers, on-disk .minio.sys format, and Go module paths are all preserved and frozen by a CI compatibility guard.
• Native health checking: silo healthcheck [live|ready|cluster|cluster-read] probes the server’s own health API with correct exit codes, decoded quorum diagnostics, TLS auto-detection, and a --maintenance pre-drain gate — no shell, curl, or mc required in the container.
• Distroless image pilot: pgsty/silo:<RELEASE>-distroless ships exactly one program — the silo binary — on gcr.io/distroless/static, with an exec-form HEALTHCHECK baked in and /data created writable in the image layer.
• The classic image does not change behavior: same entrypoint, same bundled tools, mc ready local keeps working, and no HEALTHCHECK was added to it. It now bundles mcli 20260806.
• Compliance completed: LICENSE and NOTICE ship in every package and image, CREDITS is regenerated from the actually-linked module set (291 modules) and guarded in CI, and the project adopts a no-CLA, DCO-based contribution policy.
• Components refreshed: embedded SILO Console 2.1.1, silo-pkg 3.11.0, mcli 20260806, Go 1.26.5.
• Provenance-gated releases: container images are built only from published, checksum- and attestation-verified release archives; image SBOMs and provenance attestations now cover the distroless variant too.

The rename

What changed, and what deliberately did not:

The server presents its own identity — silo --version reports the AGPL-3.0 license, MinIO’s 2015-2025 copyright, PGSTY’s modification copyright, and the “based on MinIO technology” attribution — and every inherited connection to MinIO-operated services (the update feed and its signing key, SUBNET, telemetry) is severed rather than redirected. The container entrypoint translates the legacy minio argv token, so docker run pgsty/silo minio server /data keeps working.

A snapshot-based rebrand guard runs in CI: it fails on any drift, in either direction, across 334 route literals, 437 environment tokens, 84 headers, and 9,014 exported symbols.

Native health checking

The server binary can now probe its own health endpoints, which makes container health checks possible without any second binary — and is what the distroless image relies on:

silo healthcheck [FLAGS] [live|ready|cluster|cluster-read]

• The check vocabulary maps 1:1 onto /minio/health/<path>; live (the default) answers “is this process serving,” ready adds KMS/etcd reachability when configured, and the cluster pair evaluates write/read quorum across every erasure set.
• Exit codes are 0 (healthy) and 1 (anything else) — never the Docker-reserved 2. One diagnostic line decodes the server’s x-minio-server-status and quorum headers for docker inspect; --json emits a machine-readable verdict.
• The probe target is derived the way the server derives its own listen address: --address / MINIO_ADDRESS, with HTTPS auto-detected from public.crt + private.key in the certs directory, or overridden wholesale with --url / MINIO_HEALTHCHECK_URL. The environment form exists because a probe process cannot see the server’s command line — if the server’s address or TLS comes from CLI arguments, one environment variable redirects the baked-in probe.
• silo healthcheck --maintenance cluster answers the pre-drain question: exit 0 means the node can be taken down without losing HA; HTTP 412 (exit 1) means it cannot.
• Certificate verification is skipped, matching the kubelet’s documented behavior for HTTPS probes, and the transport ignores HTTP_PROXY so loopback probes never route through a proxy.

Kubernetes needs none of this — kubelet httpGet probes hit /minio/health/live and /minio/health/ready from outside the container — and the cluster checks should stay out of per-container probes: they reflect cluster-wide quorum, not one process. The full design rationale, including verified endpoint semantics, is recorded in the health-check design note.

Distroless image pilot

Alongside the classic image, this release publishes a distroless variant: pgsty/silo:RELEASE.2026-08-06T00-00-00Z-distroless, plus a rolling distroless tag.

• Base is gcr.io/distroless/static-debian12: CA certificates, tzdata, /tmp, and an /etc/passwd with a nonroot (65532) entry — no shell, no package manager, no libc. On top of it, exactly one program: /usr/bin/silo (plus the license set under /licenses/). The image is 128 MB versus the classic 199 MB.
• The binary is the ENTRYPOINT; an exec-form HEALTHCHECK running silo healthcheck ready is baked in (interval 30s, timeout 10s, start-period 2m, retries 3), so Compose users get working depends_on: condition: service_healthy with zero configuration.
• /data is created in the image layer, world-writable — there is no entrypoint left to repair volume ownership at runtime, and this is what makes every privilege mode work, --user included. This fixes, for the distroless variant, the non-root failure documented in #55.
• Not supported in this variant: the deprecated MINIO_USERNAME/MINIO_GROUPNAME privilege-drop path (use --user or Kubernetes runAsUser), docker exec <c> sh debugging (use ephemeral-container tooling), and in-image mc (use the released mcli or the client image).
• TLS: mount certificates at /tmp/.silo/certs (the container’s default certs directory) and both the server and the baked-in probe derive HTTPS from the same location; for CLI-configured servers, set MINIO_HEALTHCHECK_URL.

The classic image remains the default and is unchanged. If the pilot proves out, the distroless variant becomes the recommended image later; the decision record lives in the design note above.

Container images

The classic image was diffed field by field against pgsty/minio:RELEASE.2026-08-04T00-00-00Z: entrypoint, exposed ports, volumes, working directory, user, and (absent) health-check configuration are identical. Exactly three differences exist, all deliberate: Cmd is ["silo"] instead of ["minio"], the upstream update-verification key variable MINIO_UPDATE_MINISIGN_PUBKEY is removed (updates through upstream channels are permanently disabled), and HOME=/tmp is declared to match the entrypoint’s writable-home guarantee.

The bundled client is upgraded to mcli RELEASE.2026-08-06T00-00-00Z (with the mc alias preserved), pinned by per-architecture SHA-256 digests and verified against the published checksums at build time. Interoperability of the released mcli 20260806 against this server — multipart, versioning, presigned URLs, metadata/tags, user and policy administration — was verified as part of release acceptance.

Helm chart

The chart ships as silo 7.0.1, preserving rendered resource identity with the legacy chart across a simulated upgrade (verified by the migration guard over 7 rendered resources). Its default image tag now points at this release — docker.io/pgsty/silo is a fresh repository, so the inherited default could never have pulled. The chart still ships no liveness/readiness/startup probes; adding them is planned, and documented, in the design note’s follow-up phase.

Packaging and migration

RPM, DEB, and APK packages install exactly six files: /usr/bin/silo, silo.service, a sysusers definition (creating the silo system user), /etc/default/silo (marked config/noreplace), LICENSE, and NOTICE. RPMs are GPG-signed with the PGSTY maintainer key (9592A7BC 7A682E73 33376E09 E7935D8D B9BD8B20). RPM and DEB now carry a unified, PGDG-style 1PGSTY release segment — silo-<version>-1PGSTY.<arch>.rpm and silo_<version>-1PGSTY_<arch>.deb — replacing the inherited bare -1 on RPM and the missing revision on DEB; APK names stay bare because Alpine pkgrel admits only -r<integer>.

silo.service is designed for takeover: Type=notify (readiness is signaled by the server itself), Conflicts=minio.service + After=minio.service (starting Silo stops a running MinIO unit), and two environment files — /etc/default/minio is read first and /etc/default/silo overrides it — so an existing MinIO configuration is inherited without editing. For existing deployments whose data is owned by the minio user, the documented drop-in keeps ownership untouched:

# /etc/systemd/system/silo.service.d/10-legacy-user.conf
[Service]
User=minio
Group=minio

Migration troubleshooting, from the acceptance run: if Silo starts as the packaged silo user against a deployment whose TLS certificates live under the minio user’s home, it fails with HTTPS specified in endpoints, but no TLS certificate is found and restart-loops until the systemd start limit — the legacy-user drop-in above is the fix. Keep the MinIO package and unit installed (disabled) during the migration window: the rollback path — stop Silo, start MinIO — was rehearsed and reads all data written during the Silo window, because the migration touches neither data ownership nor format.

Components and dependencies

• SILO Console 2.1.1 — the embedded console, selected from pgsty/silo-console while preserving the github.com/minio/console import path.
• silo-pkg 3.11.0 — retains the policy/LDAP/certificate fixes including the LDAP-over-TLS repair tracked in #15.
• mcli 20260806 — bundled in the image and released separately; see its release notes.
• Go 1.26.5 — toolchain unchanged from 20260804.

Build, CI, and release pipeline

• Compatibility as a CI gate: the rebrand guard snapshots routes, environment tokens, headers, metrics, storage/policy identifiers, and exported symbols, and fails on any unreviewed drift; companion scripts assert the delivery surface (binary path, unit contents, image layout) and that no live upstream endpoint remains in runtime code.
• Release-image gate: every release-pipeline run builds both container images and asserts, among others: the distroless HEALTHCHECK survives into the image config (it is a Docker extension outside the OCI spec), /data ships world-writable, no shell and no /usr/bin/minio exist, Docker’s health state turns healthy from the baked probe alone, and SIGTERM still stops the server gracefully as root and as --user 1001:1001.
• Provenance chain: images are built from the published release archives after checksum verification and gh attestation verify against the exact tag; per-architecture SBOMs and provenance attestations are pushed for the classic and distroless images; the distroless health-check gate runs before the multi-arch manifests are promoted.
• Workflow runtime moved to Node 24 across CI actions.

Compatibility and upgrade notes

1. Package upgrades are a takeover, not an in-place update. Install silo, keep /etc/default/minio as is (it is inherited), enable silo.service; starting it stops minio.service via the conflict relation. Data is untouched.
2. Keep data ownership stable with the legacy-user drop-in above; do not chown storage or move certificates during migration.
3. Distributed clusters: full-stop switchover only. See the warning above — mixed Silo/MinIO nodes do not form a cluster.
4. Container users: the image is now docker.io/pgsty/silo; docker.io/pgsty/minio stays frozen at 20260804 as an archive. The classic image’s behavior is unchanged — including mc ready local health checks — and the distroless variant is strictly opt-in.
5. Distroless differences are deliberate: no shell, no in-image mc, no MINIO_USERNAME path; health is native; servers configured via CLI arguments need MINIO_HEALTHCHECK_URL for the baked-in probe.
6. Helm users: chart 7.0.1’s defaults now pull this release; override image.tag explicitly if you pin versions.
7. Known and unchanged: the classic image still does not create /data in the layer, so fully non-root docker run against a Docker-managed volume fails as before (#55, fixed in the distroless variant); the inherited Postgres/MySQL legacy notification-migration limitation from the 20260804 notes still applies (#53).
8. Pair with mcli 20260806 for the client side; older clients continue to work over the unchanged wire protocol.

Verification

This release was verified in stages, each with recorded evidence:

• unit and end-to-end matrices for the health-check command: target derivation and precedence (flag/env/derived), real-TLS auto-detection, exit-code contract, JSON schema, timeout bounds, usage errors;
• cluster-semantics verification on a four-node cluster: with 2 of 4 nodes stopped, cluster reports 503 with write-quorum=5 while cluster-read and live stay 200 — the write/read quorum split observed live, matching the erasure math;
• image acceptance: the classic image diffed field-by-field against the 20260804 baseline; the distroless image asserted down to file inventory, exact health-check configuration, and root/non-root/TLS/env-override runtime scenarios;
• an adversarial model-based code review of the new code, with every confirmed finding fixed and re-verified;
• a six-phase pre-release acceptance concluding in a real migration: a Pigsty-deployed four-node TLS MinIO 20260804 cluster (16 drives, EC:4) was migrated to Silo via the packaged takeover path — reference data (multipart, versioned, tagged objects) read back byte-identical, four maintenance-gated rolling restarts, kill -9 fault injection with the load balancer serving 23/24 continuous IO rounds (the only failure in the kill second), Prometheus metrics continuity, and a full rollback to MinIO and back, proving the migration reversible.

Validation boundaries

Not proven by this release and not to be inferred: external LDAP/OIDC/KMS/etcd services (the only case where ready diverges from live was not exercised against a live KMS); amd64 packages were cross-built and payload-checked but not installed on a physical x86-64 host; the renamed Docker publish workflow (including the new SBOM/attestation lanes) has its first production run at this release’s publication; Windows and Intel macOS were not tested.

Artifacts

• GitHub release RELEASE.2026-08-06T00-00-00Z at pgsty/silo, with checksummed platform archives, provenance attestations, and RPM/DEB/APK packages (GPG-signed RPMs);
• docker.io/pgsty/silo:RELEASE.2026-08-06T00-00-00Z and latest; docker.io/pgsty/silo:RELEASE.2026-08-06T00-00-00Z-distroless and distroless — published on demand from the finished release;
• companion releases: mcli 20260806, silo-pkg 3.11.0, embedded SILO Console 2.1.1;
• design record: Native Health Checks and the Distroless Image.

Selected changes

• 15def34dc, 77bdc4c0c: drop upstream delivery residue; present Silo identity and close inherited upstream services
• 15ab10833: rename the delivery artifacts to silo and complete the package payload
• 30749911b: ship the silo binary in the image and translate the legacy argv command
• e071bb77e: replace the minio chart with a silo chart that preserves identity
• bd8df5166: gate the rebrand on compatibility, packaging, and provenance evidence
• 6613c2a3c: pin the external test fixtures and run the suites against the silo binary
• fd2ca1c6d, c46b16ec6, c47733abc, f1c77d5a2: cut over to pgsty/silo and main; document the archived branch
• 6740e6978: move the workflow actions onto the Node 24 runtime
• b57275be3: adopt the no-CLA plus DCO policy and fix copyright terms
• 62717d7bf, a6d6d9b02: update the embedded Console to 2.1.0, then 2.1.1
• 6bd9cf77e: regenerate CREDITS from the linked module set and guard it in CI
• 219670d31: ship LICENSE and NOTICE in every package and image
• 2ff594f4b: add the native silo healthcheck subcommand
• 4c34d2309: add the distroless image variant as a pilot
• b6d47b739, 9462cce16: harden both per adversarial review; lint cleanup
• 16b78eb4e: bundle mcli 20260806 and point the Helm defaults at this release
• 062a91bee: pin the CREDITS module closure to the shipped linux target
• 467931455: unify the rpm and deb release segment as 1PGSTY
• b14ea22aa: match checksum manifest entries exactly in the image publish lane
• 3be10fcc1: add a manual finalize lane refreshing SBOMs and checksums for signed Draft packages

Acknowledgments

Four contributors have code merged into this fork, and the Git history carries their authorship: @ZouhairCharef patched CVE-2026-34986 in go-jose (#18), @mfredenhagen patched CVE-2026-39883 in OpenTelemetry (#19), @pinginfo implemented Flush on trackingResponseWriter to repair bucket notification streaming (#34), and @waterkip repointed the documentation links to the Silo portal (#41).

A first release under a new name is also the right moment to thank everyone who has filed issues against this fork — bug reports, compatibility findings, and proposals alike, resolved and still open:

@mosesdd (#1), @Xavier-777 (#2, #17), @jiadzh (#3), @TLINDEN (#4), @AntonOfTheWoods (#5), @zylpsrs (#6), @nsanitate (#7), @makinikm (#9), @magicxor (#10), @spaceg00se-r (#11, #14), @heroes1412 (#13), @vampywiz17 (#15), @davinkevin (#20), @chalukyaj (#30), @cbornet (#31, #32), @jvasile (#33), @Kesavaambati (#35), @redfoxfox (#38), @kuldeep-link11 (#39, #40), @meesudzu (#42), @pmezhuev (#43), and @kh0mka (#51).

Several of this release’s headline items trace directly back to those reports: the bundled-client guarantee to #4 and #9, the LDAP-over-TLS repair to #15, the completed package payload to #33, GPG-signed RPMs to #43, the migration guide to #42, and the distroless /data fix to #55.

Pull requests still in flight deserve a mention too. @davinkevin’s distroless image PR (#21) anticipated this release’s pilot months in advance — the shipped variant supersedes that PR with the native health check built in, but the direction was proposed there first. Conformance PRs from @magicxor (#12) and @ycjlin (#37) are queued for review immediately after this release.

Everyone who has contributed to this fork is recorded in CONTRIBUTORS.md, which is now the project’s attribution record — GitHub generates no contributor graph for forks.

2.18 - Silo 20260804 Released

Version: RELEASE.2026-08-04T00-00-00Z · Commit: d88f46ccee345a9c2fabe2d221d9a9e56bc11aec

SILO 20260804 is a security, correctness, and release-engineering update to the pgsty/minio community fork. It completes the internode storage-containment work begun with CVE-2026-42600, prevents request-controlled values from impersonating server-calculated S3/IAM policy conditions, restores streaming flush behavior, fixes several multipart and versioning edge cases, hardens notification configuration migration, moves the build baseline to Go 1.26.5, and connects the server to the SILO-maintained Console, shared package, and mcli releases. The release pipeline was rebuilt to produce reproducible binaries and GPG-signed packages.

The release covers 50 commits after the pre-2026-06-18 baseline, changing 155 files with 9,241 insertions and 981 deletions. Every change was reviewed against the tagged commit and verified on macOS ARM64 and Linux AMD64, with GitHub CI green on the released HEAD.

Highlights

• Internode containment completed: validates storage-REST message bodies, storage Grid frames, and peer-S3 Grid requests at the storage boundary, closing the remaining path, volume, erasure-metadata, panic, and unbounded-allocation defects left after removing ReadMultiple.
• S3/IAM decisions now use effective values: client input can no longer shadow internal condition values; request tags and existing-object tags are separated; s3:signatureAge is confined to verified presigned requests; and s3:versionid follows the version the server actually acts on.
• Bucket and object resources are separated: twelve sensitive bucket-level writes are no longer authorized through an object-only bucket/* resource pattern. A documented compatibility switch is available for migration.
• Multipart compatibility and correctness improved: full-object checksum completion works without per-part checksums when the protocol permits it, zero-length multipart checksums are preserved, and duplicate part numbers are rejected instead of assembling duplicated data.
• Streaming reliability restored: trackingResponseWriter now implements Flush correctly and records implicit HTTP 200 responses, repairing mcli watch, bucket-notification listeners, and S3 Select keep-alives affected by the inherited regression documented in the 20260618 release.
• Notification configuration hardened: NATS and AMQP keys used by parsers and legacy migration are registered and round-trip correctly; libpq connection parameters are quoted safely; invalid-key errors no longer echo secret values.
• Reproducible, signed release pipeline: binaries no longer embed the build machine’s paths, packages install under the canonical systemd path, and RPMs are GPG-signed. The container entrypoint now shuts down gracefully on every privilege path.
• Release baseline refreshed: Go 1.26.5, klauspost/compress 1.18.7, Apache Thrift 0.24.0, SILO Console 2.0.0, silo-pkg 3.11.0, and mcli 20260804.

Security Hardening

Internode storage and Grid containment — SN-2026-002

Removing the obsolete ReadMultiple endpoint in 20260618 closed one reachable path but did not close the underlying defect class. Storage-REST request bodies and Grid RPC frames do not pass through the HTTP query-validation middleware, and peer-S3 RPCs can bypass the storage-REST wrapper entirely.

This release moves containment to the storage boundary and validates every caller-controlled path, volume, erasure parameter, part size, shard length, and allocation length before use. The fixes include:

• reject traversal on both path and volume axes, including Windows volume-root aliases;
• cover peer-S3 bucket RPCs that reach drives without the storage-REST wrapper;
• reject zero or unusable data/parity/block-size combinations before shard arithmetic;
• reject negative part sizes and truncated shards instead of reporting them healthy;
• cap storage-REST ReadFile allocations at 5 GiB;
• bound other allocations derived from internode declarations;
• contain panics in deadline-bounded storage work without blocking the caller;
• preserve ReadParts errors across keep-alive responses and avoid the empty-part trace panic.

These routes require cluster-root or internode credentials and are registered only in distributed-erasure deployments. Single-node S3 behavior is unchanged. See Internode Path Containment Audit for the protocol-surface analysis.

Effective policy-condition values — SN-2026-003

The policy condition map historically mixed values calculated by the server with raw request entries. A client-controlled spelling could therefore shadow or synthesize an internal condition value. SILO 20260804 pairs silo-pkg 3.11.0’s exact-key lookup rule with server-side source normalization:

• internal condition names cannot be supplied as arbitrary client values;
• s3:prefix, s3:delimiter, and s3:max-keys come from their effective query inputs;
• header-backed x-amz-* conditions do not accept unrelated query substitutes;
• when storage class or upload tagging supports both forms, an explicitly present Header wins, including an empty Header;
• s3:ExistingObjectTag/* comes only from stored object metadata;
• s3:RequestObjectTag/* is bound to the tag input consumed by the relevant operation;
• s3:signatureAge is exposed only after verified SigV4 presigned authentication calculates it;
• s3:versionid is absent when no version is named and is rebound per DeleteObjects entry to the effective resolved version.

The version-ID behavior closes the fail-open trap that a superficial “omit empty values” fix would have created for Multi-Delete. See Absent Is Not Empty.

Bucket/object resource boundary — SN-2026-004

The IAM matcher used to append a slash to a bucket-level request, allowing an object-only resource such as arn:aws:s3:::bucket/* to authorize selected bucket-level operations. This release withholds twelve sensitive writes from that pattern on Allow statements:

PutBucketPolicy, DeleteBucketPolicy, PutBucketObjectLockConfiguration, PutBucketVersioning, PutReplicationConfiguration, PutBucketLifecycle, DeleteBucket, ForceDeleteBucket, PutBucketCors, DeleteBucketCors, PutBucketQOS, and PutInventoryConfiguration.

Deny and NotResource behavior is unchanged. Read/list operations, CreateBucket, bucket tagging, default encryption, and notification configuration remain compatible. Built-in policies use Resource: "*" and are not affected.

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

Trusted client-address boundary

MINIO_API_TRUSTED_PROXIES provides an enforceable, opt-in boundary for aws:SourceIp, audit remotehost, event notification Host, and the client address shown by mcli admin trace:

• set it to an address/CIDR list to trust forwarding headers only from those peers and walk forwarding chains from right to left;
• set it to none to ignore all forwarding headers;
• leave it unset to preserve historical behavior exactly.

The old _MINIO_API_XFF_HEADER=off switch still suppresses only X-Forwarded-For; it does not protect against X-Real-IP or RFC 7239 Forwarded. If IP-based policy is part of your security boundary, configure trusted proxies explicitly and prevent direct access to the S3 API port. Multi-node deployments should allow their own node addresses. See Client Source Address Trust.

S3 and Storage Correctness

Multipart upload

• CompleteMultipartUpload accepts the S3 full-object checksum mode when the completed request supplies no per-part checksums and the upload metadata does not require them.
• The checksum of a zero-length multipart object is retained instead of being discarded as empty metadata.
• Part numbers must be strictly increasing. Duplicate entries such as [1,1] now return InvalidPartOrder instead of consuming the upload and assembling the same part twice. Legal part lists with gaps or a non-1 start remain accepted. See Duplicate Part Numbers.

Object reads and buffer ownership

• erasure reads again pool buffers only where ownership permits reuse;
• update downloads return caller-owned buffers instead of exposing data that can be overwritten after return;
• the old HTTP streaming helpers orphaned by ReadMultiple removal are deleted after reference and platform-tag checks.

HTTP response tracking and S3 Select

• trackingResponseWriter.Flush() delegates to the underlying flusher and commits the response state correctly;
• the first implicit write records HTTP 200, preserving audit and metric accuracy;
• S3 Select tests no longer race a client parser against response-body ownership;
• CSV, JSON, and Parquet selection paths remain covered, including range/error and keep-alive behavior.

The inherited silent-flush regression called out in SILO 20260618 is therefore fixed in this release.

IAM, Versioning, and Audit Behavior

• DeleteObject and each entry in DeleteObjects evaluate s3:versionid against the effective version selected by the server.
• Request tags can no longer impersonate existing-object tags during policy evaluation.
• The merrs tag is restored when dangling-object deletion records are emitted, preserving the intended audit classification.
• Bucket-policy and IAM paths share the hardened condition-source rules while retaining their established S3 routing and error behavior.

Notification Configuration

• registers the NATS user_credentials, nkey_seed, and tls_handshake_first keys read by the parser;
• separates the legacy NATS environment-variable spelling from the stored config key;
• repairs NATS migration round trips and the AMQP immediate/internal mapping;
• adds a mechanical audit that compares keys read and written by notification code with each subsystem’s registered schema;
• quotes libpq connection-string parameters so whitespace, quotes, and backslashes retain their intended value;
• prevents invalid-key diagnostics from echoing secret values.

See Notify Keyspace Registration.

Components and Dependencies

• Go 1.26.5: includes security fixes in crypto/tls and os plus compiler, runtime, networking, and syscall corrections.
• klauspost/compress 1.18.7: refreshes the compression stack used by object and archive paths.
• Apache Thrift 0.24.0: updates the dependency compiled through Parquet support.
• go-systemd 22.6.0: deliberately retained instead of 22.7.0 because the later version introduced a NetBSD clock dependency incompatible with the supported cross-build matrix.
• SILO Console 2.0.0: the embedded console is selected from pgsty/silo-console while preserving the compatible github.com/minio/console import path.
• silo-pkg 3.11.0: provides the companion policy, LDAP, certificate, RNG, and time-format fixes while preserving the github.com/minio/pkg/v3 module path.
• mcli 20260804: the embedded client comes from pgsty/mc; release images expose it as mcli and keep the mc compatibility alias.

See the companion release notes for silo-pkg 3.11.0, mcli 20260804, and SILO Console 2.0.0.

Build, CI, and Packaging

This release rebuilt the release pipeline for reproducibility and supply-chain integrity:

• Graceful container shutdown on every path. The entrypoint’s custom UID/GID branches now exec into the server so it runs as PID 1 and receives SIGTERM directly; previously those branches left an intermediate shell as PID 1 and the server was killed at the container stop timeout. A CI smoke test builds the release runtime image and asserts graceful shutdown on both the default and drop-privilege paths.
• Reproducible binaries. Release binaries no longer embed the build machine’s GOPATH/GOROOT, so -trimpath holds and a third party rebuilding the tag gets matching bytes. The published Linux binary contains no build-host path.
• Hardened release workflow. The release tag is passed through the environment and whitelisted rather than spliced into the shell, the build is checked out at the tag being released, and an untracked shadow GoReleaser config that could publish or move latest out of band was removed.
• Honest gates. CI gates build, vet, unit tests, lint, generation drift, race tests, and cross-compilation; the cross-compile matrix is aligned to the exact set of published targets; and the lint and dependency-install steps now fail on real errors instead of masking them.
• Signed, canonical packages. RPM, DEB, and APK packages are produced with nFPM under the PGSTY identity, the systemd unit installs at /usr/lib/systemd/system/minio.service with Type=notify, and RPMs are GPG-signed offline with the PGSTY maintainer key (fingerprint 9592A7BC 7A682E73 33376E09 E7935D8D B9BD8B20).
• Release and container publication remain separate gates. GoReleaser produces the platform archives, checksums, and packages; the multi-architecture image is published on demand from the finished release. A local snapshot does not prove a public release or image exists.

Compatibility and Upgrade Notes

1. Keep every node on one release during a cluster rollout. Internode validation changed across storage-REST and Grid surfaces; mixed binaries were not production-tested.
2. Audit custom IAM policies. Add the bare bucket ARN for the twelve protected bucket writes. Use MINIO_API_LEGACY_BUCKET_RESOURCE_MATCH=on only as a temporary migration control.
3. Configure client-address trust deliberately. If aws:SourceIp or audit attribution matters, set MINIO_API_TRUSTED_PROXIES and close direct network paths around the proxy.
4. Review legacy database notification settings. Convert Postgres/MySQL host/user/password fields to the supported connection-string format before restart.
5. Expect duplicate multipart completion entries to fail. Clients sending the same part number more than once now receive InvalidPartOrder instead of a corrupted successful object.
6. Use the matching mcli. The 20260804 client disables self-update and must be upgraded through packages or GitHub Releases; mcli update remains as a compatibility command but exits non-zero.
7. RPM users can enable signature verification. Packages are signed with the maintainer key above; import it before enabling gpgcheck for the SILO packages.

Verification

Changes were reviewed against the tagged commit and re-verified rather than trusted from prior reports:

• git diff --check, gofmt, module verification, and YAML/shell syntax;
• go build ./..., go vet ./..., project lint, and govulncheck ./...;
• full go test ./..., the complete race suite, and repeated race tests over storage, policy, notification, HTTP tracking, and S3 Select changes;
• generator idempotence plus deliberate stale-source and untracked-output counterexamples;
• cross-compilation across every published target;
• Linux AMD64 native full tests, targeted race tests, live S3/mcli smoke tests (create/upload/download/copy, range, versioning, delete markers, health checks, graceful shutdown, restart persistence), and systemd notify behavior;
• release-artifact verification: GitHub CI green on the released HEAD, reproducible binaries with no build-host path, the systemd unit installed at /usr/lib/systemd/system, and RPM signatures validated with rpmkeys --checksig.

govulncheck found no vulnerability reachable from the Server or mcli code. One module-level notice remains for the unmaintained golang.org/x/crypto/openpgp package (GO-2026-5932); that package is not imported into these binaries.

Validation boundaries

The following were not proven by this release and must not be inferred from cross-compilation or unit tests:

• native Windows execution and Windows filesystem semantics;
• Intel macOS and physical Linux ARM64 hosts;
• a production multi-node rolling upgrade, site replication, or lifecycle expiration run;
• real reverse-proxy chains and direct-ingress isolation;
• external LDAP, OIDC, KMS, STS, Postgres, MySQL, NATS, and AMQP services;
• installing and upgrading the signed package under a real systemd host.

Artifacts

• GitHub release RELEASE.2026-08-04T00-00-00Z with checksummed platform archives for Linux, Darwin, and Windows on amd64 and arm64;
• RPM, DEB, and APK packages under the PGSTY identity, with GPG-signed RPMs;
• docker.io/pgsty/minio:RELEASE.2026-08-04T00-00-00Z and the release-selected latest tag, published on demand from the release;
• matching SILO Console 2.0.0, silo-pkg 3.11.0, and mcli 20260804 references.

Selected Changes

• ca7baa670, 80e8eaa42, b6f70ab08: validate internode paths, erasure metadata, and allocation sizes
• a36fd8fff: contain panics in deadline-bounded storage work
• 2f55347f7: bind S3/IAM policy conditions to effective request values
• 744a9dcd7: bind s3:versionid to the effective object version
• 97b7d2804: enforce the bucket/object resource boundary
• fe6dc4780: add the trusted-proxy client-address boundary
• 22c1e41fd: reject duplicate multipart part numbers
• c8590413f, 3e14733f1: restore full-object and zero-length multipart checksum behavior
• 8069a32ac, 65795ee1f: restore response commit and streaming flush semantics
• 162ded343, 0c14d8151: repair notification key registration and libpq quoting
• 924717926, 89d346bf5: restore safe buffer pooling and returned-buffer ownership
• 3b8a55dee: exec into the dropped-privilege process so signals reach the server
• 2ca4971d9: stop stamping the build machine’s paths into the binary
• 4c185d5a6, e064b5555: harden the release workflow and remove the shadow config
• aa5139369: install the systemd unit under /usr/lib
• 11d79fddc, ca674a696, 021110b45, d88f46cce: gate build, vet, tests, lint, generation, race, and cross-compilation, and smoke-test the release image

2.19 - mcli 20260804 Released

Published: 2026-08-04 · Version: RELEASE.2026-08-04T00-00-00Z

This is the first release of the pgsty/mc community fork since 20260417. It fixes a credential leak in debug logging, severs every remaining connection between the client and upstream release channels, moves containers and packages onto artifacts this fork builds itself, and migrates packaging from MinIO’s pkger to standard nFPM — with GPG-signed RPMs for the first time.

Upstream minio/mc was archived in July 2026. Its final commit, 77f82e18, is exactly this fork’s base, and upstream never cut a release containing it — so this build is strictly newer than any official mc binary ever published.

Major Changes

• Self-update disabled, upstream release channels severed: the minio/selfupdate and aead.dev/minisign dependencies and all binary-replacement logic are gone, along with the update notifier and the FIPS/non-FIPS update paths. The update command survives as a compatibility shell, and the runtime helpers (Docker / DCOS / Kubernetes / source-build detection) moved to a dedicated cmd/runtime-info.go. The client previously reached out to upstream release feeds on every invocation to print an upgrade hint; there is now no outbound release probing at all.
• Containers and artifacts fully localized: the default image is built from the checked-out fork source, and hotfix binaries are copied from the local build context — no upstream prebuilt binaries are downloaded. The upstream publishing files Dockerfile.release, Dockerfile.release.old_cpu, and docker-buildx.sh were removed, and the obsolete MinIO hotfix upload target is disabled.
• Packaging migrated to nFPM: replaced MinIO’s pkger with standard nFPM. Artifact layout and install path are unchanged (/usr/local/bin/mcli, package name mcli, YYYYMMDDHHMMSS.0.0 version scheme), but the vendor is now PGSTY, the license uses the SPDX identifier AGPL-3.0-or-later, and the Debian Section moved from empty to utils.
• RPMs are now GPG-signed: RPMs are signed offline with the maintainer key (fingerprint 9592A7BC7A682E7333376E09E7935D8DB9BD8B20). All package metadata is asserted before signing, and the signature is re-verified with checksums regenerated afterwards. DEB and APK packages carry no package-level signature; their trust anchor lives at the repository layer.
• Build provenance hardened: every previously published binary was stamped by the Go toolchain as built from a modified working tree (vcs.modified=true), which broke the link between an artifact and its Git tag. This release fixes that and adds an enforcing check to both the release and test pipelines, so every binary is traceable to an exact commit.

Security Fixes

• SUBNET credentials redacted in debug logs: with --debug enabled, SUBNET HTTP exchanges are printed in full. Previously the api-key / api_key query parameters, authentication headers, and response bodies all reached the log in clear text — and SUBNET’s authentication and registration endpoints return API keys, licenses, and tokens in their responses. Both parameter spellings and duplicate values are now masked uniformly, sensitive response headers are redacted, and SUBNET response bodies are excluded from debug dumps entirely. The leak is inherited from upstream and present in every previous release, upstream mc included: if you have ever shared --debug output of SUBNET commands (mcli license ... / mcli support ...), treat the API keys and licenses in it as exposed and rotate them.
• Redaction isolated from caller state: debug tracing now dumps copies of the request and response, so redaction cannot mutate objects the caller still holds. Zero-length, fixed-length, and unknown-length response bodies are all covered, and callers can still read the response normally.

Dependency Updates

This cycle’s dependency work is security maintenance, not routine hygiene: every bump below except the term / mod / sync / tools refresh closes at least one published advisory in the Go vulnerability database, and govulncheck reports zero known vulnerabilities reachable from this release’s code. No security advisory has ever been published for minio/mc, minio-go, madmin-go, or minio/pkg themselves.

• Go build baseline upgraded from 1.26.2 to 1.26.5 (the newest 1.26.x at release time), picking up the 1.26.3–1.26.5 security batches — including GO-2026-4970 (symlink-based root escape in os) and GO-2026-5856 (Encrypted Client Hello privacy leak in crypto/tls), the two most relevant to an S3 client that writes local files and speaks TLS.
• github.com/klauspost/compress from v1.18.5 to v1.18.7 (closes GO-2026-5841).
• github.com/prometheus/prometheus from v0.310.0 to v0.311.3 (closes GO-2026-5264, GO-2026-5381, GO-2026-5710).
• google.golang.org/grpc from v1.79.3 to v1.82.1 (closes GO-2026-6061), with the genproto family refreshed alongside.
• The golang.org/x/* family refreshed across the board: crypto v0.49.0 → v0.53.0 (the 14-advisory GO-2026-5005…5033 batch), net v0.52.0 → v0.56.0 (GO-2026-5025…5030 and GO-2026-5942), sys v0.42.0 → v0.46.0 (GO-2026-5024), text v0.35.0 → v0.39.0 (GO-2026-5970), plus term, mod, sync, and tools.
• Removed aead.dev/minisign and github.com/minio/selfupdate, and synchronized the third-party credits file.

Engineering and Delivery

• Integration test dependencies pinned: CI no longer downloads the MinIO server from a mutable upstream URL. It now uses a versioned pgsty/minio release archive verified by its SHA-256 digest, with Go pinned to 1.26.5.
• Release pipeline verification: a packaging validation workflow compares the binary inside all three package formats byte-for-byte against the build output, and checks package names, checksums, architecture fields, and every metadata field. The expected RPM metadata is sourced from the signing script itself, so configuration drift cannot strand a release part-way through signing.
• CI supply-chain hardening: every GitHub Action is pinned to a commit SHA with dependabot keeping them current, workflow permissions are narrowed to read-only, and a stale workflow pointing at the upstream organization’s project board was removed.
• Documentation: the English and Chinese READMEs now state this fork’s distribution channels and self-update policy explicitly, and installation instructions that would silently install upstream mc were removed.

Related Commits

• 9603ee3: fix: redact SUBNET secrets in HTTP debug logs
• f6ae2b0: fix: disable self-update in Pigsty builds
• c05a6e4: build: update Go deps and toolchain to 1.26.5
• 1f105aa: build: use local fork artifacts for containers
• 1182da5: ci: pin fork integration test dependencies
• 9ee207f: docs: clarify Pigsty fork distribution channels
• 0686cd8: fix: isolate SUBNET debug redaction
• ad10a2a: build: complete local Docker context isolation
• 5f54221: docs: update mc README and cn version
• 02c0305: build: migrate release packaging to nFPM
• 4c4dcc4: build: harden release provenance and package metadata

2.20 - Silo 20260618 Released

Published: 2026-06-18 · Version: RELEASE.2026-06-18T00-00-00Z

This release is a security and dependency-maintenance update for the pgsty/minio fork. It hardens LDAP STS throttling, completes S3 Select oversized-record enforcement, removes the obsolete ReadMultiple internode storage-REST API, upgrades the Go build baseline to 1.26.4, and refreshes Go module dependencies to pick up additional third-party security fixes.

Major Changes

• Remove the obsolete ReadMultiple storage-REST API: the legacy /rmpl internode endpoint is removed rather than patched in place, including its route, handler, client wrapper, storage interfaces, xlStorage methods, generated datatypes, and related metric. No production caller is expected after upstream multipart handling moved to ReadParts, but clusters should still run a consistent release during rolling upgrades.
• Complete S3 Select oversized-record enforcement: JSON Lines input now uses the bounded reader path, so oversized records are rejected consistently instead of bypassing limits on SIMD-capable CPUs. S3 Select stream errors now preserve the intended error code and wrap JSON parser failures as JSONParsingError.
• Harden LDAP STS rate-limit source bucketing: throttling is now keyed only by source IP, avoiding username-shared buckets that could be drained by one client to lock out a legitimate user. Trusted-proxy handling now resolves X-Forwarded-For from right to left, rejects catch-all trusted-proxy CIDRs, ignores RFC 7239 Forwarded, and documents the X-Real-IP deployment contract.
• Refresh the Go runtime and module baseline: release, hotfix, goreleaser, and old-CPU Docker builds now use golang:1.26.4-alpine; go.mod is updated to Go 1.26.4; and dependencies are refreshed across NATS, Prometheus, Azure SDK, Apache Thrift, gRPC, OpenTelemetry, Google API/auth, Go x/*, and related transitive libraries.

Direct Security Fixes

• CVE-2026-42600: remove the obsolete ReadMultiple storage-REST API to close the legacy internode file-read path exposed through /rmpl.
• CVE-2026-39414: complete oversized S3 Select record enforcement for JSON Lines inputs and preserve correct S3 Select error semantics.
• CVE-2026-33419: further harden LDAP STS rate-limit accounting and trusted-proxy source-IP handling.

Dependency Security Updates

• Update github.com/Azure/go-ntlmssp from v0.1.0 to v0.1.1, fixing CVE-2026-32952, where malformed NTLM challenges could panic a Go process.
• Update github.com/apache/thrift from v0.22.0 to v0.23.0, fixing CVE-2026-41602 in the Go TFramedTransport implementation.
• Update github.com/nats-io/nats-server/v2 from v2.11.1 to v2.11.15, absorbing the NATS 2.11.x security patch line. Notable fixes include pre-auth WebSocket and leafnode denial-of-service issues, MQTT authorization issues, JetStream management API authorization hardening, credential exposure fixes, and request identity-spoofing fixes, including CVE-2026-27889, CVE-2026-29785, CVE-2026-33217, CVE-2026-33218, CVE-2026-33222, and CVE-2026-33247.
• Update github.com/prometheus/prometheus from v0.310.0 to v0.311.3, absorbing Prometheus security fixes for remote-read denial of service, stored XSS in UI surfaces, and remote-write configuration secret exposure, including CVE-2026-42154, CVE-2026-44903, CVE-2026-42151, and CVE-2026-40179.
• Upgrade the release build baseline through Go 1.26.4 and refresh supporting Go module families, including golang.org/x/crypto, golang.org/x/net, golang.org/x/sys, golang.org/x/text, google.golang.org/grpc, and OpenTelemetry. These updates keep the fork aligned with patched upstream dependency baselines even where the previously pinned version was already past the specific public advisory range.

Related Commits

• 5e40665: fix: harden LDAP STS rate-limit source bucketing
• fd69c89: fix: complete CVE-2026-39414 S3 Select record limit enforcement
• 73ac524: fix: CVE-2026-42600 remove ReadMultiple storage-REST API
• df627ff: fix: bump Go toolchain to 1.26.4
• 3e61b1d: chore: update Go module dependencies

2.21 - Silo 20260417 Released

Published: 2026-04-17 · Version: RELEASE.2026-04-17T00-00-00Z

This release focuses on security hardening and compatibility tightening. It bundles fixes across OIDC, LDAP STS, S3 Select, replication metadata handling, unsigned-trailer flows, the Snowball upload path, and multiple dependency- and Go toolchain-related security issues, while also incorporating the LDAP TLS regression fix and a cleanup of community-fork documentation.

Major Changes

• Tighten the identity-authentication flow: OIDC / WebIdentity now accepts only asymmetrically signed ID Token values backed by the IdP JWKS; symmetrically signed tokens such as HS256 are no longer accepted. LDAP STS also now hides the distinction between unknown-user and bad-password failures to reduce username-enumeration risk.
• Update LDAP STS rate limiting: limits now apply to both source IP and normalized username, and successful requests no longer consume quota incorrectly. By default MinIO now uses only the socket peer address as the source and no longer trusts X-Forwarded-For, X-Real-IP, or Forwarded; to rate-limit by real client IP, configure MINIO_IDENTITY_LDAP_STS_TRUSTED_PROXIES explicitly.
• Make upload and write paths stricter: presigned query parameters can no longer be combined with unsigned-trailer PUT or multipart uploads. Snowball auto-extract now also performs full signature validation on the unsigned-trailer path and rejects anonymous or forged-signature requests.
• Prevent replication metadata spoofing: internal X-Minio-Replication-* headers attached to ordinary PUT / COPY requests are now rejected or ignored, and only trusted replication flows may write the related internal metadata.
• Clarify S3 Select error semantics: oversized CSV and line-delimited JSON records now return OverMaxRecordSize directly instead of the generic InternalError; clients or alerting rules that depend on the old error code should be adjusted.
• Upgrade the runtime and dependency baseline: fix the regression where ldaps:// did not correctly apply TLS settings, replace minio/pkg/v3 with pgsty/minio-pkg/v3, and pin several critical dependencies that are prone to breaking changes. The release also upgrades go-jose, go.opentelemetry.io, and Go 1.26.2 to unify the build and release baseline.
• Refresh documentation and security guidance: update SECURITY.md, VULNERABILITY_REPORT.md, docs/sts/ldap.md, and related documents, add a security advisory index, and switch upstream minio/minio references in the security guidance over to pgsty/minio.

Fixed CVEs

• CVE-2026-34986: upgrade go-jose to v4.1.4 and fix known security issues in the JWT / JOSE dependency chain.
• CVE-2026-39883: upgrade the go.opentelemetry.io dependency stack to fix the PATH-hijacking risk.
• CVE-2026-33322: restore the strict JWKS-only OIDC JWT verification path to block keyring injection and algorithm-confusion risk.
• CVE-2026-33419: systematically harden LDAP STS authentication, rate limiting, source-address identification, and accounting logic across four follow-up fixes.
• CVE-2026-34204: reject injection of X-Minio-Replication-* metadata by untrusted requests to prevent objects from being written with invalid replication state.
• CVE-2026-39414: reject oversized S3 Select records early to avoid continued buffering and parsing of abnormal inputs.
• GHSA-hv4r-mvr4-25vw: close the unsigned-trailer query-auth bypass.
• GHSA-9c4q-hq6p-c237: harden unsigned-trailer authentication and signature validation in Snowball auto-extract scenarios.
• CVE-2026-32280, CVE-2026-32281, and CVE-2026-32283: upgrade Go to 1.26.2 and absorb the upstream toolchain and stdlib security fixes.

Related Commits

• ce1c537: fix: pin deps with breaking changes and fix LDAP TLS regression (#15)
• 68e0ba9: fix: upgrade go-jose to v4.1.4 to patch CVE-2026-34986
• 1869bd3: fix: CVE-2026-39883 upgrade go.opentelemetry.io
• ff58df9: merge: PR #18 upgrade go-jose to v4.1.4 for CVE-2026-34986
• e4fa063: merge: PR #19 upgrade go.opentelemetry.io for CVE-2026-39883
• d24f449: fix: CVE-2026-33322 restore JWKS-only OIDC JWT verification
• 3b950f8: fix: CVE-2026-33419 harden LDAP STS auth
• 56fa63b: fix: CVE-2026-34204 reject untrusted replication metadata
• 3252d5b: fix: CVE-2026-39414 reject oversized S3 Select records
• f444b6f37: fix: fake CVE-2026-40027 block unsigned-trailer query auth bypass
• efb6e5b00: fix: fake CVE-2026-40028 harden snowball unsigned-trailer auth
• db4c0fd: fix: CVE-2026-32280/CVE-2026-32281/CVE-2026-32283 upgrade Go to 1.26.2
• 18b712d: fix: CVE-2026-33419 preserve LDAP STS rate limits on success
• 9e10f6d: fix: CVE-2026-33419 harden LDAP STS rate-limit source IP
• f441108: fix: CVE-2026-33419 tighten LDAP STS rate-limit accounting
• f48dbe7: docs: refresh security guidance and fork references

2.22 - Silo 20260325 Released

Published: 2026-03-25 · Version: RELEASE.2026-03-25T00-00-00Z

This is a maintenance release centered on packaging, stability, and security disclosure. It improves the shipping artifacts, fixes an LDAP TLS regression, and explicitly documents the secure dependency set carried by the release.

Major Changes

• Bundle mcli/mc into the Docker image and add checksum verification for a better out-of-the-box image experience.
• Fix the LDAP TLS regression affecting ldaps:// deployments so TLS settings are correctly honored.
• Remove inherited upstream CI/CD workflows that are no longer used in the community-maintained fork.
• Pin several critical dependencies to avoid further fallout from upstream breaking changes.

Fixed CVEs

• CVE-2026-24051: the release notes explicitly call out go.opentelemetry.io/otel/sdk v1.42.0, which avoids the macOS PATH-hijacking arbitrary code execution issue.
• CVE-2025-10543: the release notes explicitly ship github.com/eclipse/paho.mqtt.golang v1.5.1, fixing incorrect MQTT packet encoding for oversized UTF-8 strings.
• CVE-2025-58181: the release notes explicitly ship golang.org/x/crypto v0.49.0, fixing unbounded memory consumption in ssh GSSAPI authentication handling.

Related Commits

• f2f9a40: add mcli/mc from pgsty/mc to Docker image
• ce1c537: fix: pin deps with breaking changes and fix LDAP TLS regression (#15)
• ee55e53: remove upstream CI/CD workflows inherited from minio/minio

2.23 - Silo 20260321 Released

Published: 2026-03-21 · Version: RELEASE.2026-03-21T00-00-00Z

This maintenance release is built around the Go 1.26.1 upgrade and a broad dependency refresh. Beyond stricter compiler and linter compatibility fixes, it also delivers the most substantial security dependency refresh in the current release line.

Major Changes

• Upgrade the build environment from Go 1.26.0 to Go 1.26.1.
• Refresh direct and indirect dependencies to converge on the newer toolchain.
• Fix linter and test issues exposed by the stricter Go 1.26.1 checks.

Fixed CVEs

• CVE-2026-27137: Go stdlib 1.26.0 -> 1.26.1 fixes incomplete email-constraint enforcement in crypto/x509.
• CVE-2026-27138: Go stdlib 1.26.0 -> 1.26.1 fixes a crypto/x509 panic triggered by malformed certificates.
• CVE-2026-25679: Go stdlib 1.26.0 -> 1.26.1 fixes insufficient validation of IPv6 host literals in net/url.
• CVE-2026-27139: Go stdlib 1.26.0 -> 1.26.1 fixes FileInfo metadata escaping the Root boundary in os.
• CVE-2026-27142: Go stdlib 1.26.0 -> 1.26.1 fixes missing URL escaping in html/template for meta refresh content.
• CVE-2026-26958: filippo.io/edwards25519 v1.1.0 -> v1.2.0 fixes incorrect or undefined MultiScalarMult behavior.
• CVE-2025-10543: github.com/eclipse/paho.mqtt.golang v1.5.0 -> v1.5.1 fixes incorrect MQTT packet encoding for oversized UTF-8 strings.
• CVE-2026-24051: go.opentelemetry.io/otel/sdk v1.38.0 -> v1.42.0 fixes the macOS PATH-hijacking arbitrary code execution issue.
• CVE-2026-33186: google.golang.org/grpc v1.77.0 -> v1.79.3 fixes authorization bypass caused by a missing leading slash in the HTTP/2 :path pseudo-header.

Related Commits

• 5abd9a8: bump golang to 1.26.1 and update deps
• 377fc61: fix: satisfy stricter Go 1.26.1 linter checks

2.24 - Silo 20260314 Released

Published: 2026-03-14 · Version: RELEASE.2026-03-14T12-00-00Z

This release switches the project to the community-maintained Console fork and performs a sizeable dependency refresh to establish the base for the later Go 1.26.x maintenance releases.

Major Changes

• Switch to the community-maintained georgmangold/console v1.9.1 fork in place of the unmaintainable upstream Console dependency.
• Refresh a large portion of the direct and indirect dependency graph so the new Console and toolchain combination builds cleanly.
• Fix the go vet format directive issue in grid_test.go and adjust tests for the HTTP behavior changes in Go 1.26.

Fixed CVEs

• CVE-2025-47913: golang.org/x/crypto v0.37.0 -> v0.46.0 fixes a panic in ssh/agent when handling malformed responses.
• CVE-2025-58181: golang.org/x/crypto v0.37.0 -> v0.46.0 fixes unbounded memory consumption in ssh GSSAPI authentication parsing.
• CVE-2025-47914: golang.org/x/crypto v0.37.0 -> v0.46.0 fixes a panic in ssh/agent caused by malformed identity messages.
• CVE-2025-47911: golang.org/x/net v0.39.0 -> v0.48.0 fixes quadratic parsing complexity in html.Parse for crafted inputs.
• CVE-2025-58190: golang.org/x/net v0.39.0 -> v0.48.0 fixes an infinite parsing loop in golang.org/x/net/html.

Related Commits

• 68521b3: add github ci/cd pipeline
• 00f3cf7: RELEASE.2026-03-14T12-00-00Z with go 1.26.0

2.25 - Silo 20260214 Released

Published: 2026-02-14 · Version: RELEASE.2026-02-14T12-00-00Z

This early infrastructure-focused community release restores the embedded Console, introduces GitHub CI/CD, and lifts the Go baseline to 1.26.0, which also absorbs a batch of security fixes from the older toolchain generation.

Major Changes

• Restore the embedded Console and refresh the README to clarify the community fork position.
• Add GitHub CI/CD workflows as the base for automated builds and multi-platform delivery.
• Add quick links for docs, Docker, the GitHub repository, and installation through the pig package manager.

Fixed CVEs

These issues were absorbed as part of the Go 1.25.5 -> 1.26.0 upgrade:

• CVE-2025-68121: crypto/tls could incorrectly accept mutated CA configuration during session resumption.
• CVE-2025-61730: TLS 1.3 could process handshake messages incorrectly across encryption-level boundaries.
• CVE-2025-61726: net/url query parsing could be abused for memory exhaustion.
• CVE-2025-61728: archive/zip could consume excessive CPU while building archive indexes.
• CVE-2025-68119: cmd/go could trigger unexpected code execution when invoking external VCS tooling.
• CVE-2025-61731: the #cgo pkg-config: directive could be abused for arbitrary file writes.
• CVE-2025-61732: cmd/cgo comment parsing discrepancies could enable code smuggling.

Related Commits

• 8630937: Restore embedded console and update README for community fork
• 68521b3: add github ci/cd pipeline

Historical note: CI/CD pipeline evidence now links maintained-history commit 68521b37f. It preserves the pipeline files and includes a README adjustment; this does not claim the full historical commit trees are identical.

2.26 - Silo 20251203 Released

Published: 2025-12-15 · Version: RELEASE.2025-12-03T12-00-00Z

This is the earliest traceable community release. Its purpose is to establish the community packaging and distribution baseline rather than to deliver incremental fixes over an earlier community release.

Major Changes

• Build the community packaging flow around minio/pkger.
• Choose a maintenance-mode upstream MinIO baseline as the starting point for the community-maintained fork.
• Produce the first apk, deb, and rpm artifacts for ongoing community releases.

Fixed CVEs

• This is the first community release. The GitHub Release does not provide a delta-style security-fix list against an earlier community version, and this page does not attempt to reconstruct the full historical CVE delta against the upstream maintenance baseline.

Related Commits

• d4cd4b4: RELEASE.2025-12-03T12-00-00Z with go 1.25.5

3 - SILO Security Chronicle

This is the security chronicle of the SILO community fork, listed from newest to oldest. Records may cover a CVE, a SILO-local SN finding, several related repairs, or a non-vulnerability correctness audit: the original threat model, the turns taken during review, the rejected alternatives, the final invariant, the evidence, and the compatibility cost all stay with that incident.

The security ledger indexes identifiers, fixed source and first containing releases. An investigation date is not a release date, and publishing an article does not deliver a fix.

3.1 - September Security Repairs: Payload Integrity, IAM Revocation and Console Sharing

This record covers three repairs and their delivery boundaries as of September 16. The identifiers are SILO-local advisory numbers, not CVEs or assigned CVSS scores. The security ledger is the maintained index.

Presigned payload integrity — SN-2026-012

The generic authenticated path could verify a presigned request using a payload hash supplied only in X-Amz-Content-Sha256, yet omit checking the actual body against that hash. A holder of a suitably signed write URL could replace its body. The committed regression demonstrates this with PutBucketPolicy; this is not a claim that an anonymous caller can write arbitrary bucket policies.

c4b5e1cb4 in PR #177 binds body validation to the effective signed hash; mismatches fail with XAmzContentSHA256Mismatch (400). An explicit signed UNSIGNED-PAYLOAD retains its intended meaning. The adjacent signed-field fixes align policy conditions with authenticated values and remove the X-Amz-Signature-Age scratch header. They complement SN-2026-011; they do not establish complete unsigned-header coverage for streaming SigV4.

Review custom signing clients before upgrading. Query hash values take precedence over the fallback header, so changing an unsigned header must not change what policy evaluation or body validation sees.

Durable IAM revocation — SN-2026-013

Delayed replication events, parent recreation and lost deletion history could restore identities or grants an operator had revoked. PR #191 and PR #192 retain source revisions, deletion tombstones and signed parent-revocation boundaries. Older events and child credentials cannot silently cross a retained revocation boundary.

This is a persistent-state change. Upgrade all sites and all nodes sharing an IAM backend together; mixed old/new nodes and rolling downgrade are unsupported. mcli admin cluster iam export omits deletion history and is not a complete recovery backup. Preserve a tested full-backend recovery point and reconcile known earlier revocations. Tombstones have no TTL or automatic compaction.

The design record documents ordering, remaining group-membership limitations and metrics. Follow the upgrade and recovery procedure, including the password-policy pre-step. A revocation can commit and then return HTTP 500 if cleanup fails; the response alone does not prove that the old credential is valid.

Anonymous Console share proxy — SN-2026-014

Jiri Pejchal reported that the unauthenticated shared-download proxy accepted URLs beyond the intended object-download surface on its configured Server origin. This is a same-origin proxy-boundary issue; it is not evidence of arbitrary-host SSRF or bypass of the Server’s S3 authorization.

Console #56 constrains scheme, host and port, requires a valid bucket/object path, rejects system and traversal paths and operation-changing query selectors, disables redirects, and propagates caller cancellation. Accepted object URLs retain their original signed bytes.

Upgrade a standalone installation to Console v2.4.1. Server #209 selects the fixed Console source on main, but installing a separate Console cannot patch the UI and proxy compiled into Server 20260903. Until an appropriate Server artifact is available, limit exposure of the affected Console share endpoint according to the deployment.

Adjacent dependency hardening

Server main upgrades amqp091-go to v1.14.0 for GHSA-6c5v-hqjr-5xxp, fixed upstream in v1.13.0. A malicious AMQP peer can trigger excessive allocation; the SILO path requires a configured AMQP notification target. This Server change also awaits a release after 20260903. pkg v3.14.1 separately ships the JWX JSON encoding update. Component publication and Server dependency adoption are separate facts.

3.2 - SN-2026-011: Fix and Release Status

Status on 2026-09-13: SN-2026-011 is fixed on Server main, starting with 123325430. The latest published Server, RELEASE.2026-09-03T13-18-01Z, and earlier public Server releases are affected. No new fixed Server release is established by the pkg v3.14.0 or mcli 20260913 publication.

A holder of a signed PUT request could add an unsigned x-amz-copy-source header and turn the permitted write into a copy of another object readable by the signing key. A destination that permits anonymous reads can expose those copied bytes. This affects both presigned and Authorization-header requests; the holder does not need the signing credentials.

The patch checks the received x-amz-* headers against the signed-header set, with the protocol’s explicit exceptions, before dispatching the requested operation. Follow-up request-signing and checksum regressions are documented in the signed-header review.

Operators must update the Server to source containing the fix or a future release that explicitly includes it. Restrict write-signing credentials to the required objects and avoid exposing unnecessary read grants or anonymous readable upload destinations while planning that update. Updating a client or Console alone does not remove the Server defect.

Reported by Oren Yomtov. The advisory ledger records SN-2026-011 and its source fix; a CVE was requested. Do not substitute a dependency scan’s clean reachability result for this application-level status. See the component matrix for released versus main source and the Server changelog for the remaining release contents.

3.3 - CVE-2025-62506: Session-Policy Privilege Escalation

Status: Inherited and released
First Silo community release: RELEASE.2025-12-03T12-00-00Z
Upstream fixed release: RELEASE.2025-10-15T17-29-55Z
GitHub advisory: GHSA-jjjj-jwhf-8rgr
Upstream fix: minio/minio#21642

A service account or STS account with a restricted session policy could use an “own account” operation to create another service account without the restriction. The child account then inherited broader parent permissions, turning valid low-privilege credentials into a privilege-escalation path.

Silo did not need a separate backport. The upstream fix and its two regression groups were already in the history from which the community fork was released. This note records that inheritance without duplicating the tests or reconstructing the investigation already captured by the upstream advisory and PR.

Commit mapping

The identical SHA is the mapping: this is inherited source history, not an independent Silo implementation with a merely similar patch. The advisory ledger keeps the same source-to-fork record.

Regression evidence

PR #21642 added two regression groups and runs each against root and non-root parents:

• TestServiceAccountPrivilegeEscalationBug2_2025_10_15 covers restricted service accounts.
• TestSTSPrivilegeEscalationBug2_2025_10_15 covers restricted STS accounts.

Both remain wired into the standard cmd test suites, so go test ./cmd executes them. No parallel or replacement regression test was added for this publication update.

Fix and operator boundary

When a session policy exists, the fix clears the DenyOnly shortcut before evaluating it. An “own account” exception therefore cannot turn “not explicitly denied” into permission: the restricted policy must actually allow the action.

Every Silo community release contains this commit. Operators migrating from a MinIO build older than the upstream fixed release should upgrade, review service accounts created by restricted service or STS identities, and revoke suspicious child accounts. This inheritance statement does not extend support to historical Silo releases; the current release line remains the supported line.

3.4 - SILO 20260903 Security Notes: SN-2026-006 through 010

Released in SILO 20260903. These fixes are part of RELEASE.2026-09-03T13-18-01Z. See the complete release notes for the 20260806-to-20260903 upgrade boundary, components, verification evidence, and known deferrals.

This bulletin collects five related security findings from the final SILO Server review. They cover customer-provided encryption keys, client-controlled replication headers, administrative status changes, and explicit object-version deletion.

The identifiers SN-2026-006 through SN-2026-010 are fork-local security-note IDs. They are not CVEs, are not registered in a vulnerability database, and should not be represented as such. The individual CVE chronicle remains one article per CVE; this release bulletin groups findings without CVEs so operators can evaluate one upgrade boundary.

All five defects were inherited from the archived minio/minio lineage and affect every earlier SILO release. “Inherited” describes provenance, not severity.

Summary

No finding in this bulletin is an unauthenticated remote-code-execution claim. Each requires an authenticated identity or existing object permission, but each crosses a privilege or cryptographic boundary beyond that identity’s intended grant.

SN-2026-006: zero-byte SSE-C key authentication

Affected operations: GetObject, HeadObject, CopyObject source processing, and GetObjectAttributes for zero-byte objects encrypted with SSE-C.
Tracking: issue #82.
Fixes: b73581b05 and c4fd97d0b.

SSE-C stores a sealed object key and requires the caller to provide the customer key again on reads. Normal reads authenticate that key while preparing the encrypted stream. A zero-byte object has no payload block, and the old fast path returned before unsealing the stored object key.

Consequently, an incorrect customer key could receive a successful response. A copy or new version could also be created under a key chosen by the caller without proving knowledge of the current key. The caller still needed read access to the object; the failure was that object permission replaced the separate cryptographic proof.

The fix authenticates the key independent of payload length. Correct keys behave as before. Wrong keys fail with 403 AccessDenied, including null-version and key-rotation cases.

SN-2026-007: SSE-C GetObjectAttributes

Affected operation: GetObjectAttributes on SSE-C objects.
Tracking: issue #84.
Fixes: 474cd5801, 74c97d005, and 21870fa2e.

GetObjectAttributes exposes object size, ETag, checksums, storage class, and multipart part metadata. The inherited handler returned those attributes without authenticating the supplied SSE-C key. It also treated the presence of X-Minio-Source-Replication-Request as permission to skip key handling.

The repair separates two cases:

• an ordinary S3 caller must supply the correct SSE-C key;
• a real replication peer may use the replica path only after authentication and s3:ReplicateObject authorization.

A wrong key now returns 403. A bare marker without the required key and permission cannot create the replica exception. Existing replication identities that already hold the required action keep working.

SN-2026-008: replication headers are not authority

Affected surface: object reads and writes, multipart completion, object and version deletion, Snowball extraction, Object Lock timestamps, checksum metadata, and bucket events.
Tracking: PR #101.
Primary fix range: 938603458 through 04b097fd9, followed by Snowball and rule-prefix hardening.

CVE-2026-34204 stopped ordinary PUT and COPY requests from importing a subset of replication SSE metadata. The wider audit found that many other consumers still treated header presence as proof that a request was internal replication.

Depending on the operation, a client holding ordinary read or write permission could:

• request an SSE-C ciphertext/no-decryption path without the customer key;
• preserve a supplied source ETag or modification time;
• inject source checksum, actual-size, retention, legal-hold, or replica-state metadata;
• choose replication-only delete semantics;
• suppress successful object events;
• carry trust from one Snowball archive entry into another.

The repair defines one receiver-wide authority:

1. authenticate the original request in its signed form;
2. require exactly one marker with the exact lowercase value true;
3. authorize s3:ReplicateObject or s3:ReplicateDelete on the addressed resource;
4. derive a narrower replica-trusted state only where replica status also proves it;
5. store the decision in private request context;
6. strip untrusted internal headers from a clone after authentication.

The context decision is authoritative. Stripping protects older consumers but cannot itself grant trust. The clone preserves the original trailer map so streaming checksum authentication remains correct.

The detailed protocol matrix, CORS interaction, black-box replication test, and rejected alternatives are in No I/O Before Auth, No Privilege From Headers.

SN-2026-009: user and group status authorization

Affected operations: admin SetUserStatus and SetGroupStatus.
Tracking: PR #73 / PR #85.
Fixes: 58735ee38 and 229fe2b3c.

The inherited handlers checked admin:EnableUser or admin:EnableGroup regardless of the target state. A narrowly delegated administrator permitted to enable an identity could therefore disable it too; an identity intended to hold only the disable action could fail or be evaluated against the wrong grant.

The requested state now determines the required action:

admin:* and the built-in consoleAdmin policy remain sufficient. Only custom least-privilege policies that accidentally relied on one action for both directions need adjustment.

SN-2026-010: explicit object-version deletion

Affected operations: DeleteObject and each DeleteObjects entry carrying an explicit versionId.
Tracking: issue #58 and PR #104.
Fix range: 75a6734e4 through d2d47a41f.

The inherited S3 path authorized explicit version deletion as ordinary s3:DeleteObject and used s3:DeleteObjectVersion only as a secondary deny check. This diverged from AWS and let a principal with ordinary delete permission permanently remove a selected historical version.

The release requires s3:DeleteObjectVersion for explicit versions. A delete without versionId continues to use s3:DeleteObject. Replication targets keep their s3:ReplicateDelete contract.

There are two policy effects:

1. a principal granted only s3:DeleteObject can no longer delete explicit versions;
2. a policy using Allow s3:* together with Deny s3:DeleteObject to block permanent deletion must also deny s3:DeleteObjectVersion.

The multi-delete repair preserves authentication and audit context for every entry and has least-privilege tests for ordinary and replication deletes.

Operator actions

Before upgrading:

1. identify policies and applications that delete explicit versions; grant or deny s3:DeleteObjectVersion intentionally;
2. inspect custom admin policies for enable/disable user and group operations;
3. confirm that replication service accounts have only the required s3:ReplicateObject / s3:ReplicateDelete actions and that ordinary application identities do not;
4. verify SSE-C integrations send the same customer key for GET, HEAD, attributes, and copy-source operations, including zero-byte objects;
5. if an application was relying on a wrong SSE-C key returning success, treat that as a latent client defect and correct it before rollout.

After upgrading:

• exercise a wrong-key negative test and a correct-key positive test on a disposable SSE-C object;
• test one normal replication and one delete replication operation;
• test each delegated admin direction independently;
• test version deletion with a principal that has only s3:DeleteObject and with one that also has s3:DeleteObjectVersion;
• review audit logs for unexpected denied operations instead of widening policies immediately.

Verification boundary

The fixes have focused unit, handler, authorization, streaming-trailer, Snowball, and site-replication tests. Full local acceptance on ebac0ca73 included the complete cmd race suite and six deployment shapes with 174 PASS / 0 FAIL. The final line adds one CORS state-clear fix after that run and passes targeted race, compatibility, generation, diff, and lint gates.

The final RELEASE.2026-09-03T13-18-01Z publication completed the gates recorded in the pre-release review: exact-SHA CI and Test Release, signed packages, checksums, SBOMs, provenance, and public classic/distroless container images. This bulletin still scopes its claims to the five fixes above and the residual risks below.

Residual risks outside this bulletin

• Conditional deletion is still unsupported: DeleteObject ignores If-Match and DeleteObjects ignores per-object ETag (#10).
• Non-CORS policy/SSE/tag/quota deletions may not converge across site-replication peers (#77).
• The trust audit focused on known replication and SSE-C fields. New internal headers must still answer the same provenance-and-authorization question during review.

The release notes contain the full known-issue and deployment boundary.

3.5 - CVE-2026-32285: The jsonparser Advisory That Required No Patch

Status: Closed without a code change
GitHub issue: pgsty/minio#26

Security maintenance is not always a sequence of “find a vulnerability, then ship a patch.” The initial assessment of CVE-2026-32285 was that the repository might still carry a vulnerable jsonparser; replacing the dependency or maintaining another fork was even considered. Checking the resolved module version and actual reachability changed the conclusion: the tree already used v1.1.2, which contained the fix, and govulncheck found no reachable vulnerable symbol.

The right final action was not to manufacture an upgrade. It was to record the evidence and close the issue.

What was wrong with the initial assumption

The issue was first understood as “this dependency has no fixed version.” Acting on that premise without verification could have produced several changes that looked proactive but made the project worse:

• changing the dependency graph for no security benefit;
• introducing compatibility regressions in the name of a nonexistent fix;
• adding another fork that would need long-term maintenance;
• implying that previous SILO releases were demonstrably exposed when that had not been established.

Security work cannot be measured by whether it produces a diff. Leaving correct code unchanged is itself a security decision, and it needs evidence.

Investigation

The investigation narrowed the question through four layers of evidence:

1. Confirm the version actually selected in the current go.mod and go.sum graph.
2. Check the upstream release and establish that v1.1.2 already contained the relevant fix.
3. Run and inspect govulncheck; it reported no reachable vulnerable symbol.
4. Attribute the discrepancy in the issue to stale advisory or vulnerability-database information, not to a vulnerability still present in the source tree.

Four claims must remain separate: a version was once listed as affected, a package is imported, a vulnerable symbol is reachable in the program, and remote input can actually exploit that path. None of them proves the others.

Why there was no “just in case” upgrade

If the selected version already includes the fix, bumping to an arbitrary newer version does not make the system safer. It only expands the change surface and makes later regressions harder to attribute. That is especially risky in a large Go module graph.

The final decision was therefore to:

• avoid committing a fictitious fix;
• preserve the version and reachability evidence in the issue;
• keep version gates and govulncheck in place to detect a future dependency rollback;
• treat “no change required now” as a dated conclusion, not a permanent exemption.

Verification boundary

This incident established that the checkout examined on 2026-04-15 did not require a code change for CVE-2026-32285. It does not establish that every future branch, module graph, or release will remain unaffected. A dependency downgrade or a change in module selection requires the version and reachability checks to be repeated.

This article records the investigation and the basis for closure. The original govulncheck was not rerun while preparing this chronicle.

The principle this incident left behind

The objective of security maintenance is an accurate risk conclusion, not a patch for every issue. For a dependency CVE, ask in order: which version is actually selected, whether the vulnerable code enters the program, whether the symbol is reachable, and whether a deployed entry point makes it exploitable. Only when those answers require a source change should the investigation produce a diff.

3.6 - CVE-2026-33322: OIDC JWT Algorithm Confusion

Status: Released
First containing release: RELEASE.2026-04-17T00-00-00Z
Affected entry points: AssumeRoleWithWebIdentity, AssumeRoleWithClientGrants
GitHub issue: pgsty/minio#22

The old implementation placed the OIDC client secret in the JWT verifier keyring while also accepting HMAC signing methods. An attacker who knew that client secret could therefore mint an HS-signed token and exchange it through STS for temporary credentials. The final fix restored asymmetric, JWKS-only verification. It deliberately broke HS256/384/512 compatibility instead of keeping an option that would reintroduce ambiguous trust semantics.

The vulnerability was not the absence of signature verification

At first glance, the old code did verify JWT signatures. The boundary that failed was more specific: which kind of key the verifier would accept, and whether the token header could select an algorithm with semantics that did not match that key’s intended role.

The attack chain required several conditions:

• the attacker obtained the OIDC client secret;
• the attacker constructed an HMAC-signed ID token;
• the verifier treated the client secret as an HMAC signing key;
• the token reached the WebIdentity or ClientGrants STS flow and was exchanged for temporary credentials.

Disclosure of a client secret is already serious, but it should not automatically confer the power to issue arbitrary user ID tokens. Combining those capabilities in one keyring created the algorithm-confusion vulnerability.

A compatibility path was implemented, then deliberately removed

During the fix, an allow_hmac-style compatibility path was implemented. It appeared reasonable: keep the secure default while letting users with a real requirement opt in. But retaining a shared secret in the general verifier keyring meant administrators would need to understand that the option expanded the entire STS trust boundary. Any future drift in the method allowlist could reopen the flaw.

The trade-off became clear:

The most important decision was not what code was added, but that a completed compatibility implementation was removed.

Final invariants

The fix was concentrated in the OIDC JWT verification path and established four rules:

• verifier keys come only from the identity provider’s JWKS;
• the OIDC client secret never enters the JWT verification keyring;
• HS256, HS384, and HS512 are always rejected;
• the ordinary RS256 flow and JWKS refresh/retry use the same method allowlist.

The CVE was not used as a pretext for expanding JOSE support. PS256 and EdDSA remained out of scope.

Verification and release

The development record includes HS256 rejection, RS256 acceptance, JWKS refresh/retry regression tests, and focused go test ./internal/config/identity/openid. Temporary compatibility helpers, configuration, and tests were all removed from the final diff.

The public fix is d24f449, released with SILO 2026-04-17. This article records the historical verification; those tests were not rerun while preparing the chronicle.

Compatibility cost

This is an explicit breaking change. Identity providers that still issue HS256/384/512 tokens must migrate to JWKS-backed RSA or ECDSA before upgrading SILO. The project chose a narrower trust model that is easier to explain and audit over preserving a configuration that happened to work before.

3.7 - CVE-2026-33419: LDAP STS Enumeration and the Throttling Chain

Status: Released, followed by two rounds of corrections
First containing release: RELEASE.2026-04-17T00-00-00Z
Complete correction: RELEASE.2026-06-18T00-00-00Z
GitHub issue: pgsty/minio#23

The core vulnerability was straightforward: LDAP STS returned different results for “user does not exist” and “password is wrong,” creating a username oracle. The first fix unified the external authentication failure and added limits by source IP and username. Continued review then showed that success refunds, spoofable source headers, reservation accounting, and the shared username bucket could turn the security control itself into a new attack surface.

The final June design removed the username bucket that enabled precise account lockout, retained only the source-IP bucket, and made proxy attribution an explicit deployment contract.

Initial threat model

The entry point is AssumeRoleWithLDAPIdentity. An attacker needs no existing MinIO account. Access to the LDAP STS endpoint is enough to compare the code, status, or message returned for an unknown user and a wrong password, enumerate valid usernames, and combine that knowledge with password spraying, guesses about organizational naming, or social engineering.

The fix could not simply disguise every error as “wrong password.” LDAP connection, lookup-bind, and directory-service failures still needed to appear as infrastructure errors, or operators would lose the ability to diagnose the service.

First round: uniform responses and a limiter

The initial fix on 2026-04-15 did three things:

• unknown user and bad password returned the same external STS authentication error;
• LDAP infrastructure failures still returned 500, with the real cause retained in the server log;
• a new in-memory limiter initially created buckets for both source IP and normalized username.

This closed the content side channel and raised the cost of brute-force attempts, but the limiter state machine and source attribution exposed more problems.

Second round: success, attribution, and accounting

The follow-up changes on April 16 addressed three classes of defects:

1. Successful authentication must not consume the failure allowance; the reserve/commit/cancel/refund lifecycle had to be explicit.
2. The socket peer must be used by default; X-Forwarded-For, X-Real-IP, and Forwarded cannot be trusted merely because a request supplies them.
3. Refund and capacity need hard bounds so cancel logic cannot mint tokens.

A proxy must be placed on an explicit trusted allowlist before it can influence source attribution.

Third round: remove the username bucket

Adversarial review in June overturned the intuition that “source plus username must be stronger than source alone.” A shared username bucket could be exhausted continuously from arbitrary origins. With only a low request rate, an attacker could lock a targeted account before the legitimate user ever reached an LDAP bind.

The final fix therefore:

• removed the per-username bucket;
• peeled trusted hops from XFF right to left and selected the first untrusted address;
• rejected trusted-proxy footguns such as 0.0.0.0/0 and ::/0;
• stopped using Forwarded for security-sensitive bucketing;
• allowed X-Real-IP only under a contract in which the proxy overwrites rather than forwards client input.

This turn in the review shows that a security control needs its own threat model. More dimensions of throttling do not automatically mean more security.

Rejected alternatives

Verification and release

The historical record covers limiter reserve/commit/cancel/refund behavior, concurrency, success and infrastructure failures, external equivalence of unknown-user and bad-password responses, and RemoteAddr, spoofed-header, trusted-proxy, multi-hop, and catch-all-CIDR cases. Focused package tests and builds were recorded as passing.

The LDAP security end-to-end test skips when _MINIO_LDAP_TEST_SERVER is absent, so an outer ok cannot be presented as proof of the full LDAP scenario.

The first public fix was 3b950f8. Follow-up corrections include 18b712d, 9e10f6d, f441108, and 5e40665.

Final cost and residual risk

• The limiter now keys only on source IP and gives up a hard per-account throttle across different origins.
• It is per-node and in-memory, not a cluster-wide password defense.
• Botnets, distributed origins, IPv6 address rotation, and LDAP bind timing remain.
• Incorrect trusted-proxy configuration can still destroy source attribution.
• A Forwarded-only deployment falls back to the peer bucket and loses granularity.

Rate limiting can reduce attempts from one source. The uniform external authentication response is what actually conceals whether a username exists.

3.8 - CVE-2026-34204: Replication Metadata Injection

Status: Released
First containing release: RELEASE.2026-04-17T00-00-00Z
GitHub issue: pgsty/minio#24

Ordinary PUT and COPY requests could smuggle X-Minio-Replication-* headers into internal X-Minio-Internal-* SSE metadata, creating objects whose replication state did not match the authorized path and could even make them unreadable. The final fix stopped accepting replication-only metadata by default, restored it only in a trusted flow authorized for ReplicateObjectAction, and sanitized CopyObject before any header consumer ran.

Threat model

An attacker needed only ordinary object-write permission, not internode credentials. The input came entirely from client-controlled X-Minio-Replication-* headers, but metadata extraction converted it into internal replication or SSE state.

Later read paths interpreted the object according to that false internal state. The result could be an unreadable object: an integrity and availability failure. Almost every production server accepting untrusted writes needed to be treated as affected.

The root problem was not the header name. It was that data from an untrusted source acquired internal semantics without passing replication authorization.

Reject the whole request, or sanitize precisely?

Rejecting an ordinary request whenever it contains a replication header is the most obvious fix. It would also turn a header clients were previously allowed to send and have ignored into a hard failure. The final design was more precise:

• the default extraction path does not accept replication-only metadata;
• ordinary PUT and COPY strip those fields first;
• only a path authorized for ReplicateObjectAction restores them;
• replica-status writes use the same trusted condition;
• legitimate multipart and Snowball replication flows explicitly restore the SSE metadata they require.

That keeps the compatibility change inside internal semantics instead of expanding it to every client carrying an extraneous header.

Why CopyObject had to sanitize early

CopyObject headers are not used only for the final metadata map. They can be consumed earlier by precondition logic and SSE-C source handling. Removing them immediately before the object write is too late: earlier consumers have already been contaminated.

The final sanitization occurs before those consumers. “Untrusted replication headers never enter internal semantics” becomes one invariant instead of a convention every downstream function must remember to enforce.

Implementation and verification

The change covered handler utilities, object handlers, and multipart handlers, with tests at several layers:

• trusted and untrusted metadata extraction at the helper layer;
• malicious PUT and COPY cases at the handler layer;
• CopyObject header sanitization;
• red/green comparison between the vulnerable parent and the patched tree;
• live-server before/after behavior showing that a malicious header no longer made an object unreadable;
• continued operation of legitimate replication, multipart, and Snowball flows.

The public fix is 56fa63b. This article preserves the historical verification boundary; no live server was started again while preparing the chronicle.

Cost and residual risk

• Internal replication headers supplied by ordinary clients are now ignored or stripped.
• Replication-only metadata must be restored explicitly inside an authorized branch.
• If a future replication entry point forgets to restore it, the result should be a functional regression rather than another untrusted write path.
• The audit focused on replication headers; it does not establish that every X-Minio-Internal-* field has undergone the same trust review.

This incident leaves a simple review question: a field that looks “internal” is not necessarily trusted. Ask where it came from and which authorization decision allowed it to acquire internal meaning.

The later CORS and replication trust design record generalizes that lesson into one receiver-wide authority for SSE-C reads, source timestamps, multipart completion, object lock, deletes, events, and pre-authentication CORS work.

3.9 - CVE-2026-39414: Oversized S3 Select Records and a SIMD Bypass

Status: Released; the second-round fix was completed in June
Initial fix release: RELEASE.2026-04-17T00-00-00Z
Complete fix release: RELEASE.2026-06-18T00-00-00Z
GitHub issue: pgsty/minio#25

The first fix in April reused the existing 1 MiB maxCharsPerRecord limit for both CSV and ordinary JSON Lines. This prevented unbounded buffering while waiting for a delimiter and returned the explicit OverMaxRecordSize error to clients. A June review then found that CPUs with SIMD support took a different simdjson fast path that bypassed the limit completely.

The final solution sent JSON Lines through the bounded reader on every CPU. The same review also corrected error mapping, parser errors, and the flush of completed records before a terminal error. SILO temporarily gave up the SIMD fast path in exchange for consistent security semantics.

Threat model

An attacker can submit or query an object containing an extremely long single record. The reader continues buffering until it sees a record delimiter, allowing memory and CPU denial of service. More subtly, the same input can select a different implementation according to the machine’s CPU features. Safe behavior on a test machine does not necessarily prove safe behavior in production.

Error semantics are part of the fix. If an oversized record appears only as a generic InternalError, clients and monitoring systems cannot distinguish an enforced security limit from a server failure.

First round: reuse the existing 1 MiB invariant

The first patch did not invent a new configuration knob. It applied the existing maxCharsPerRecord = 1 MiB rule:

• the CSV splitter and line-delimited JSON rejected oversized records before buffering or parsing them further;
• the earliest splitter error was preserved instead of being overwritten by a partial decode;
• the error propagated as OverMaxRecordSize rather than collapsing into InternalError.

This was a deliberate compatibility contraction. Clients with lines or records larger than 1 MiB now had to split their input.

Second round: a hardware-dependent bypass

Following the call chain again in June exposed this path:

JSON Lines -> simdj.NewReader -> simdjson.ParseNDStream

When simdjson.SupportedCPU() returned true, JSON Lines bypassed the bounded json.PReader. The third-party parser kept reading past a chunk boundary until it found a newline. A generic reader wrapper could not simultaneously preserve already completed records and guarantee a bound on the next record.

The final choice was not another wrapper. JSON Lines temporarily stopped using the SIMD path and always used the bounded PReader. If SIMD support returns, that implementation must enforce the same record limit itself and pass the same CPU-independent regression suite.

Stream semantics corrected in the same round

The review also fixed several adjacent behaviors:

• use errors.As to pass through errors implementing SelectError, not just one concrete type;
• have the JSON worker wrap parser failures as JSONParsingError;
• flush completed records still waiting below the batch threshold before emitting a terminal error event;
• preserve error priority in input order instead of letting a later oversized record overwrite an earlier parse error.

Those details determine whether a client sees the correct failure or a resource-limit fix that quietly broke the streaming protocol.

Deliberately left outside this CVE

• The historical mismatch between CSV AllowQuotedRecordDelimiter and the outer physical-newline splitter.
• Whether \r in CRLF counts toward the record length.
• Restoring SIMD performance without an equivalent bound.

These questions may be real, but they require independent AWS-compatibility evidence or a more complex quote-aware splitter. They did not belong in a security patch based on guesses.

Verification and release

The historical record includes oversized JSON Lines, error-code preservation, and behavior tests that do not depend on the local machine’s SIMD capabilities. go test ./internal/s3select/... -count=1 and git diff --check were recorded as passing.

The initial public fix was 3252d5b; the complete June correction is fd69c89. Those tests were not rerun while preparing this article.

Final trade-offs

• JSON Lines performance may decrease; this incident did not produce a benchmark that quantifies it.
• The 1 MiB per-record limit rejects oversized input accepted by previous releases.
• Quoted, multiline CSV semantics still need separate work.
• Any future CPU-specific fast path must share the slow path’s security tests.

The second fix leaves the central lesson: a security invariant must hold across hardware-dependent paths. A green test on one CPU does not prove that another execution engine is protected.

3.10 - CVE-2026-40344: Snowball Auto-Extract Authentication Bypass

Status: Released
First containing release: RELEASE.2026-04-17T00-00-00Z
GitHub advisory: GHSA-9c4q-hq6p-c237

Snowball’s PutObjectExtractHandler omitted the streaming unsigned-trailer authentication case. A tar stream with a forged signature could enter untar() before authentication completed, and one request could fan out into many object writes. The final fix initialized the correct reader, handled the decoded length, and completed SigV4 verification before any tar byte reached the extractor.

Why the identifier changed

The official CVE had not been assigned when the fix was written, so the commit subject used the temporary identifier fake CVE-2026-40028. The final identifier is CVE-2026-40344. The historical commit was not rewritten; the advisory and this article use the official number.

From one missing authentication case to bulk object writes

The entry point was Snowball / PutObjectExtract auto-extraction. The request used unsigned-trailer streaming, an authentication type the old handler did not cover as ordinary PUT did.

The danger was larger than one incorrectly authorized request. Once the tar stream entered untar(), that request could create multiple attacker-chosen objects. An authentication omission was therefore amplified into a bulk-write problem.

Final invariant: the extractor sees zero bytes on failure

The key statement in the fix was:

If authentication ultimately fails, untar() must have seen zero bytes.

That rule excludes “extract first, then roll back if authentication fails.” Object writes travel through several paths, and proving a complete rollback is much harder than proving that input never crossed the boundary. Authentication had to close before data entered the extractor.

Implementation

The final change:

• recognized authTypeStreamingUnsignedTrailer;
• read X-Amz-Decoded-Content-Length;
• used newUnsignedV4ChunkedReader();
• performed complete SigV4 request verification before entering untar();
• preserved valid signed Snowball requests and CRC32 trailer flows.

Verification

The historical commit and investigation record cover:

• rejection of a forged-signature Snowball unsigned-trailer request;
• rejection of anonymous Snowball writes to a non-public bucket;
• successful extraction with a valid signature and trailing CRC32;
• red/green comparison between the vulnerable parent and the patched tree;
• containerized before/after smoke tests.

The public fix is efb6e5b00. The container tests were not rerun while preparing this article.

Compatibility and residual risk

• Clients that relied on an unsigned-trailer Snowball combination whose signature was never really verified will fail after upgrading.
• Authentication now closes before extraction, but tar paths, archive-size limits, and object-count limits remain separate security surfaces.
• Snowball and ordinary unsigned-trailer requests now share a reader; future changes must regress both paths together.

The essence of the fix was not another if. It moved the authentication decision in front of the actual amplification boundary.

3.11 - CVE-2026-41145: Unsigned-Trailer Query Authentication Bypass

Status: Released
First containing release: RELEASE.2026-04-17T00-00-00Z
GitHub advisory: GHSA-hv4r-mvr4-25vw

Query-string SigV4 credentials could enter a STREAMING-UNSIGNED-PAYLOAD-TRAILER data flow, while the old code verified the signature only when an Authorization header was present. A request carrying a valid access-key identifier could therefore complete a write without a correct signature.

The final fix moved presigned rejection and SigV4 verification into newUnsignedV4ChunkedReader(), making every caller consuming that stream share one authentication boundary.

Identifier note

The official CVE had not been assigned when the patch was written, so its commit subject used fake CVE-2026-40027. The final identifier is CVE-2026-41145. The historical commit remains unchanged; public material uses the official identifier.

Root cause: authentication was coupled to transport form

The affected entry points included PutObject and PutObjectPart. The request selected STREAMING-UNSIGNED-PAYLOAD-TRAILER, with its credentials and signature in the query string rather than the Authorization header.

The old handler used header presence to decide whether to verify a signature. The body reader still consumed the data normally, silently degrading query authentication into something close to an anonymous write. The attacker needed to know a valid access-key identifier, but did not need to produce a correct signature.

The problem was not failure to parse the query parameters. It was that authentication depended on how credentials were transported instead of the trust boundary at which the stream was consumed.

Why the patch did not live in each handler

Anonymous unsigned-trailer requests were not prohibited wholesale. If bucket policy explicitly permits anonymous writes, they can still follow the anonymous authorization path. The forbidden state is the mixture of query credentials with no verification of those credentials.

Implementation and verification

The fix performs presigned rejection and SigV4 verification at the reader entry in cmd/streaming-v4-unsigned.go, while removing the gates in the PutObject and multipart handlers that depended on header presence.

New tests cover forged query PUT, multipart, mixed authentication, and anonymous policy. The historical record also includes a vulnerable-parent write that succeeded, failure on the patched tree, and live-server before/after smoke tests showing that header-authenticated and valid anonymous flows continued to work.

The public fix is f444b6f37. The live exploit was not rerun while preparing this article.

Compatibility and residual risk

• Presigned/query unsigned-trailer is now explicitly unsupported, an intentional breaking change.
• Moving the fix into the reader significantly reduces the chance that a sibling handler omits the check again.
• Other streaming authentication modes still need their own audits; this reader fix does not establish that every SigV4 streaming combination is safe.

The shape of this fix matters as much as its payload: when several handlers share an authenticated data stream, authentication belongs to the reader rather than to optional checks in each caller.

3.12 - CVE-2026-42600: ReadMultiple Storage-REST Path Traversal

Status: Released
First containing release: RELEASE.2026-06-18T00-00-00Z
GitHub advisory: GHSA-xh8f-g2qw-gcm7
Affected scope: Distributed erasure only; cluster-root / internode JWT required

The msgpack body of /rmpl carried Bucket, Prefix, and Files. The old code joined those values into filesystem paths without a containment check. The initial fix implemented full preflight validation. Continued call-chain review then found that this API had had no production caller since 2024. The final solution changed from “retain and harden” to removing the route, handler, client, interface, and generated code.

Deleting roughly a thousand lines was a larger source diff than a local validation guard, but it left a smaller long-term attack surface.

Threat model

The vulnerable route was registered only in distributed erasure mode; single-node deployments were unaffected. An attacker needed an internode JWT derived from the root secret, control of a node, or the ability to intercept unencrypted traffic between nodes.

The dangerous fields were inside the msgpack body, not the URL or form data, so upper HTTP path middleware never saw them. xlStorage.ReadMultiple joined and read the resulting paths directly, allowing them to escape the drive root.

This was not an anonymous S3 vulnerability. It crossed the boundary from “cluster root or peer” to “any file readable by the node process.”

First design: retain the API and validate it completely

The initial patch in xlStorage.ReadMultiple:

• rejected absolute paths, . and .. segments, backslashes, Windows drive prefixes, and NUL bytes;
• checked final containment across drive, volume, prefix, and file;
• preserved the historical contract for an empty Bucket and .minio.sys/multipart where possible;
• returned an error before any read or streaming began.

That design could close the known traversal, but review quickly exposed an early-return gap.

MaxResults exposed the danger of validate-as-you-use

The first patch validated each Files item inside the read loop. For Files=[good, bad] with MaxResults=1, the function returned after reading the first item and never validated the second.

It did not read the second malicious file, but it violated the intended invariant that the entire msgpack request must be valid before execution. Validation was therefore moved into a complete preflight pass, with path-length checks also completed before streaming.

The general rule is useful beyond this endpoint: when a request can return early or stream a partial response, checking an element immediately before use is not equivalent to validating the whole request.

Final decision: delete the API

Further call-chain audit established that:

• upstream removed the last production caller in September 2024;
• multipart had moved to ReadParts;
• the current tree had no in-tree production consumer;
• upstream’s final remediation also deleted ReadMultiple.

The final change removed the route, handler, client wrapper, StorageAPI / xlStorage method, metric, datatype, and generated code. storageRESTVersion retained the existing compatibility strategy.

Verification and release

The in-place validation phase ran focused tests for xlStorage, the storage-REST client, msgpack encode/decode, and path edge cases; adversarial review exposed the MaxResults flaw. The deletion phase checked the route, client, interface, generated surfaces, and absence of callers.

The public fix is 73ac524, released with SILO 2026-06-18. The post-deletion full suite was not rerun while preparing this article.

Compatibility and claim boundary

• The external S3 API is unchanged.
• Third-party implementations that privately called the internal /rmpl endpoint will stop working.
• A mixed-version rolling upgrade may encounter a protocol mismatch, so cluster nodes should be kept on the same version during the upgrade.
• Removing this endpoint proves only that ReadMultiple no longer exists; it does not establish that every internal node request carrying body paths has completed a containment audit.

This CVE reached the right final fix, but it also leaves an important distinction: closing one endpoint is not the same claim as closing an entire vulnerability class.

3.13 - Internode Path Containment Audit: Paying Off What CVE-2026-42600 Left Owing

Release status (verified 2026-09-13): the primary fix in this article is included in 20260804 and later releases. The investigation below retains its original test boundaries; see the component matrix for current unreleased work. Affected scope: Distributed erasure only; cluster-root / internode JWT required Prerequisite reading: CVE-2026-42600 · ReadMultiple

This article is now public. The primary fix shipped as recorded above; residual findings below are the investigation-time record, not a claim that publishing one fix closed the entire defect class.

The previous entry closed with this sentence:

Deleting the endpoint proves only that ReadMultiple no longer exists. It cannot be extrapolated into a completed containment audit of every internode body path.

That was an IOU, written down in plain sight. This is the record of paying it — and a not-very-flattering construction log.

Conclusions first

• Twelve defects, all inherited from upstream. Verified by per-function md5 comparison: the fork’s diff against upstream on the affected files is pure deletion, zero added lines.
• This is not a new vulnerability. It is the remainder of CVE-2026-42600 — three more protocol surfaces under the same root cause.
• Our failure is not in the code. It is in the record: a point fix was written up as a closure.
• While fixing it we introduced four regressions of our own, every one of them in a rule we invented rather than reused.

“N endpoints” was the wrong frame

Earlier audits kept counting endpoints, arriving at 19, then 21, then 22 — and missing an entire protocol surface each time. The real structure is four surfaces:

The first row matters as much as the rest: it overturns the earlier “all 21 endpoints escapable” claim. Those audits grepped for the validation helper inside handler bodies, found nothing, and concluded there was no protection — missing that the protection lives in the middleware layer.

The fourth row is the one no amount of hardening in storage-REST handlers can reach.

The root cause is three layers, not one bug

Three design facts, none wrong on its own:

1. Validation happens only at the HTTP surface. r.Form is populated from url.ParseQuery(RawQuery) and never from a body (introduced 2017).
2. Grid RPC bypasses the middleware. /minio/grid/v1 upgrades once; subsequent msgpack frames never re-enter the HTTP chain (introduced 2023).
3. The storage layer performs no containment. getVolDir rejects a volume only when it is exactly ""/./.., and pathJoin runs Clean (settled 2018).

In one sentence: the upper layer assumes the lower one validates, the lower assumes the upper already did, and neither can see the channel in between.

ReadMultiple was merely one endpoint that exercised that structure. Removing it left the structure intact.

One line of the timeline deserves singling out. The divide-by-zero in ShardFileSize has been present since 2020, but only when it moved inside xioutil.WithDeadline in 2024-10 — a change meant to fix large-object timeouts — did it escalate from “one failed request” to “the whole process exits”, because WithDeadline runs its work function on a bare goroutine that no recover() can reach. That escalation was not visible at the time.

Vectors, confirmed by execution

Every one reproduced against a real xlStorage through the real REST/grid client, with planted sentinel files. None of this is static inference.

Two of these had never been found before and are worth calling out.

RenameFile with an empty source path hits the volume-root alias and relocates the whole volume. Aimed at .minio.sys, one ordinary S3 GET afterwards yields the cluster’s IAM and configuration. It requires no traversal sequence at all — so any audit that greps for .. misses it by construction.

A negative part size floors both terms of ShardFileSize to zero. checkPart’s only integrity test is st.Size() < expectedSize, so every file that exists is reported intact, including a truncated shard. Worse, this holds whether or not the erasure parameters are valid: metadata that passes FileInfo.IsValid() — the very check healing trusts — is affected. That is not an input-validation problem but a data-integrity one: a legitimate heal reading poisoned metadata concludes the shard is fine and skips the repair.

The fix: two chokepoints, not twenty patches

The invariant to restore is one sentence: a path from an internode payload must resolve inside the volume it names, and a volume must resolve inside the drive root.

Only .. can break the first half (absolute and backslash-prefixed paths are folded under volumeDir by pathJoin’s Clean), and the second half has one independent break: paths that alias the volume root. Two rules, therefore — not a policy matrix.

Under 40 lines of core logic. No handler is modified, no call site in xl-storage.go is touched, and the local erasure path is left alone.

Two details worth recording:

• The check must run before the join, on the raw argument. pathJoin runs Clean against an absolute drivePath, which erases a leading .. entirely — /drive/../../etc becomes /etc, so a check placed after the join reads clean and passes everything. This is the most likely way a future refactor silently undoes the fix.
• NSScanner is the one method that reaches the filesystem without getVolDir. Its guard line is load-bearing, not decorative.

Among the rejected alternatives, the notable one is adding containment at all 33 pathJoin(volumeDir, …) sinks. That would be genuine defence in depth, but it means 33 edits in the most performance-sensitive file in the tree, each needing its own judgement about whether the volume root is a legitimate target. The guard rails buy most of the same resistance to drift for a fraction of the risk. This is an explicitly recorded IOU: if a code path is ever added that reaches the filesystem without getVolDir, the decision must be revisited.

Construction log: four regressions we caused ourselves

This section is unflattering and more informative than the fix.

First: whitespace. The initial rule treated whitespace as a separator, refusing " " and " " — legal S3 object keys. PutObject commits through RenameData, so such a key would fail on every remote drive simultaneously and break write quorum. The irony: the vulnerability needs root credentials; this bug needs a user to send a space.

Second: backslash-only keys. Same function, same root cause. path.Clean never treats \ as a separator, so on Unix "\\" is an ordinary filename. Refusing it made a distributed cluster reject a write a single-node server accepts — the same S3 API behaving differently by deployment topology.

Third: spaces and periods on Windows. The Win32 normalisation layer strips trailing spaces and periods from a path component, so a component made only of those vanishes and the path resolves to its parent. That makes both " " and "..." volume-root aliases on Windows — and "..." was sitting in our own list of legal object names at the time. We had not merely missed the vector; we had asserted it was safe.

Fourth: negative part sizes. The new guard rejected only “positive size with unusable parameters”, equating “non-zero” with “positive”. Negative values take a different route to the same zero.

Two false greens

Writing the AppendFile acceptance test produced two meaningless green runs in a row:

1. Driving it through the REST client — which special-cases *bytes.Reader and derives Content-Length from it, silently overriding the forged value.
2. Switching to an opaque reader — at which point Go’s own HTTP client refuses to send a request whose body is shorter than the declared length.

Only driving the handler directly through httptest reproduced it. The lesson: a client’s self-protection is not a server’s defence, and an attacker with a raw socket has no such scruples.

A third was a design failure. We built a per-field reflection poisoner, then discarded it: it cannot distinguish “should have rejected but delegated” from “correctly allowed a non-path field” (ETag, Algorithm, …), so it reports correct behaviour as failure.

The subtlest lived in the fuzzer. The first property test treated separator-only strings as an exception with an early return. That is not an exception, it is a blind spot — the fuzzer had been shut out of the entire category by hand and could never have found the backslash key in a million executions. A wrong exception is more dangerous than no fuzzer at all, because it creates the impression the space has been searched.

A very concentrated pattern

The reused semantics produced zero regressions; the invented rules produced all of them.

This is not coincidence. hasBadPathComponent is already the object layer’s own rule via IsValidObjectPrefix, validated by real S3 traffic for years, and structurally cannot reject anything creatable through the S3 API. An invented rule has nothing behind it but the author’s imagination.

The actionable form: reuse rather than invent; and when you must invent, write the property test by exclusion rather than enumeration, express exceptions with a predicate independent of the implementation, and keep them as few as possible.

The guard rails matter more than the patch

The final test suite pulls in two directions, and neither alone is enough:

• Falsifiability — remove each guard in turn and confirm the tests actually go red (191 failing subtests with the traversal guards removed; 64 GiB and 10.4 GB reappearing with the allocation guards removed). This is precisely what the rejected community PR lacked: its test asserted err != nil against a target that did not exist, so it passes with the vulnerability fully intact.
• Legal-traffic fuzzing — asserting that any key IsValidObjectName accepts, the guards accept (1.96M executions, no violations), and that any legal bucket name survives getVolDir (810K). This is what our own first two attempts lacked.

Plus a method-level reflection rail that fails by name when a path-taking method is added to StorageAPI unguarded.

History states the case for these rails bluntly: CVE-2026-39414 was also point-fixed on 2026-04-15 and only received a fix: complete ... two months later. Counting this one, “point fix → recorded as closure → completed months later” has now happened twice in this fork. The problem is not that someone was careless. It is that nothing in the tree could tell you a class was still open. Guard rails turn “someone must remember” into “CI fails”.

On adversarial review

This fix went through five rounds of independent adversarial review. Each round found one missed defect, and all five stood: whitespace keys → backslash keys → the AppendFile allocation → Windows spaces and periods → negative part sizes.

Our own review did find two in the same period (the WithDeadline log amplification and ReadParts using the wrong rule), but only after being pushed to that standard.

The hit rate says something plain: the last gate before merge should be independent acceptance, not the author’s own conclusion. During this work the author judged the change ready to ship four times and was overturned three.

Follow-up status

The following five follow-ups were not published at the original August 3 review point. They subsequently shipped in Server 20260804:

• ReadFileHandler is bounded. Commit b6f70ab08 rejects a declared read length above 5 GiB, the maximum size of the S3 part represented by this legacy whole-file bitrot path. Legitimate GiB-scale reads can still allocate on that scale; the change removes caller-controlled allocation above the format’s real ceiling rather than pretending large reads are cheap.
• Negative part sizes cannot be persisted or trusted. Commit 80e8eaa42 rejects them at the AddVersion write funnel and again in CheckParts and VerifyFile, so both new poison and already-written metadata are covered. The internode boundary check uses the same predicate.
• Non-positive erasure block sizes are rejected at construction. Commit 80e8eaa42 validates blockSize in NewErasure, covering the other offset and decode divisions that a single downstream ShardFileSize guard could not. Rebalance’s separate division is guarded at its own boundary.
• ReadParts errors finally reach the caller (1af351a70). A pre-existing bug, fixed in passing: the handler declared success (done(nil)) before the storage call finished, so every ReadParts failure — not only the new guards, but errFileNotFound and friends too — was never returned; the client received a keep-alive stream and decoded the error text as msgpack, surfacing as msgp: attempted to decode type "int" with method for "map". After the fix, real storage errors reach quorum reduction; success paths are untouched, and that msgpack decode noise in multipart-related logs is replaced by actual storage errors.
• A recovered panic is not a healthy node (a36fd8fff). The WithDeadline recovery turns what used to be an instant process death into a stderr line (panic in deadline-bounded work: ... with a stack) plus one failed request. Stack dumps are capped at ten per process lifetime, but the error returns every time. If your alerting only watches process liveness, add a log alert for that string — otherwise a real bug that previously announced itself as a crash now only whispers in the logs.

Two limitations remain and should not be folded into a stronger claim:

• No Windows CI. Windows builds are published; tests run on Ubuntu only. The Windows rule is reasoned from documented Win32 behaviour and has not been verified on the platform.
• Symlinks. The containment check is lexical, as upstream’s is.

Closing

The previous entry said that closing an endpoint and closing a defect class are two different conclusions. This time the known sinks are closed on the local branch, at the cost of four self-inflicted regressions and three overturned declarations that it was ready to ship. At the investigation date publication remained a separate gate; these fixes subsequently shipped in 20260804.

If only one sentence survives: the vulnerability was upstream’s; our mistake was treating a point fix as a closure. And what prevents a third occurrence is not a more careful person — it is a test that fails.

3.14 - The Parser Knew, the Schema Didn't: Config Keys That Could Take Every Notification Down

Release status (verified 2026-09-13): the primary fix in this article is included in 20260804 and later releases. The investigation below retains its original test boundaries; see the component matrix for current unreleased work. Classification: Configuration-schema consistency and availability, not a vulnerability; includes one defensive hardening (credential values no longer echoed in validation errors) Affected scope: notify_nats JWT/NKey/TLS-handshake-first options, notify_amqp immediate, and any pre-2020 config migrated with an enabled NATS target — whose failure then silences every notification backend Tracking: pgsty/minio issue #39

This article names two unfixed availability defects in neighbouring code (the Postgres/MySQL migration writes, and kvFields typo folding). Neither is exploitable — both break the operator’s own configuration, loudly or not at all — and both are already named in the committed audit test’s allowlist. Publication needs no hold beyond the release itself.

Conclusions first

• Three notify_nats options — user_credentials, nkey_seed, tls_handshake_first — and one notify_amqp option — immediate — were read by the parser, written by the legacy migration, and registered nowhere. CheckValidKeys rejected exactly what GetNotifyNATS required.
• One constant meant two things. target.NATSUserCredentials held the string "MINIO_NOTIFY_NATS_USER_CREDENTIALS", sat in the environment-variable const block, and was used both as an env var name and as a config key. The snake_case config key for creds-file auth did not exist anywhere in the program.
• The reporter’s error did not come from their command. It came from the legacy migration: the pre-fix migration reproduces the issue’s error text byte for byte, including the notify_nats:ONE target name their command never mentioned. The migration wrote the store once; validation rejects it at every boot thereafter.
• The blast radius is the amplifier: FetchEnabledTargets fails fast on the first bad subsystem, its only caller just logs, and the global target list stays nil — so one broken NATS entry silently switches off Kafka, webhook, MQTT, and everything else.
• Inherited from upstream. Three feature PRs — #19139 (2024-02, user_credentials), #21008 (2025-04, tls_handshake_first), #21231 (2025-04, nkey_seed) — each added the parser and the env var, and each skipped the schema. Upstream is archived; the fork inherits both the defect and the duty.
• The fix registers the keys, splits the two-faced constant, corrects the migration — including a sibling bug that silently wrote immediate’s value under the internal key — tolerates the legacy on-disk spelling on the load path only, stops echoing values in invalid-key errors in both CheckValidKeys forms, and installs an AST audit that mechanically forbids this defect class across all ten notify subsystems.
• The audit found the next instance before the ink dried: the Postgres/MySQL legacy migrations write five unregistered keys, one of which is a plaintext database password. Recorded, allowlisted shrink-only, tracked for follow-up.

The error that named a target nobody asked about

The report (issue #39, by kuldeep-link11, against a NATS cluster using JWT operator/accounts auth) is a clean reproduction: configure notify_nats with a credentials file, watch it bounce.

$ mc admin config set us notify_nats:FITCHECK \
    address=nats-1:4222 subject=events.object.created \
    MINIO_NOTIFY_NATS_USER_CREDENTIALS=/jwt/creds/minio_notifier.creds \
    jetstream=off queue_dir=/data/queue-fitcheck queue_limit=100000

mc: <ERROR> ... found invalid keys
    (MINIO_NOTIFY_NATS_USER_CREDENTIALS=/jwt/creds/minio_notifier.creds
     nkey_seed= tls_handshake_first=off ) for 'notify_nats:ONE' sub-system,
    use 'mc admin config reset myminio notify_nats:ONE' to fix invalid keys

Two things in that error are wrong in ways the command cannot explain. The invalid-key list contains nkey_seed= and tls_handshake_first=off — keys the user never passed. And the rejected sub-system is notify_nats:ONE, while the command configured notify_nats:FITCHECK.

The second oddity is the whole case. Our reviewer established that the mc admin config set path cannot even carry an unregistered key: the server-side tokenizer, kvFields, splits the input line by searching for registered key names, so an unknown token never becomes a key at all — it is absorbed into the preceding key’s value. Probed directly:

input:  subject=s MINIO_NOTIFY_NATS_USER_CREDENTIALS=/jwt/x.creds
stored: subject="s MINIO_NOTIFY_NATS_USER_CREDENTIALS=/jwt/x.creds"

So the rejection could not have been about the command line. It was validateConfig sweeping the whole subsystem and tripping over a different, already-stored target named ONE that carried all three keys. Only one code path in the tree writes those key names into a store: the legacy config migration. Driving the pre-fix migration on an enabled NATS target named ONE reproduces the issue’s error text character for character — including the empty nkey_seed=, which is just what migration writes when the legacy config had no NKey.

That reframes the incident. This was not “the server rejected my command.” It was: an old config was migrated once, the migration wrote three keys the validator does not accept, and the store has been failing validation at every boot since — taking every other notification target down with it, silently, because the failure is logged and swallowed. The reporter’s command merely walked into the blast radius and got handed someone else’s error.

One constant, two meanings

The declaration, as inherited (internal/event/target/nats.go, pre-fix):

const (
    NATSAddress  = "address"
    NATSSubject  = "subject"
    NATSUsername = "username"
    NATSPassword = "password"
    NATSNKeySeed = "nkey_seed"            // config key — correct shape
    // ...
    EnvNATSUsername     = "MINIO_NOTIFY_NATS_USERNAME"
    NATSUserCredentials = "MINIO_NOTIFY_NATS_USER_CREDENTIALS"  // ← in the Env block
    EnvNATSPassword     = "MINIO_NOTIFY_NATS_PASSWORD"
)

NATSUserCredentials is named like a config key, valued like an env var, and shelved with the env vars. The parser used it as both: once as the env var to look up, once as the config key to read from the stored KVS. The migration used it as a key to write. There was no "user_credentials" string anywhere in the program — the config key for creds-file auth simply did not exist, which is why the reporter, finding no documented key, resorted to passing the env var name as one.

A name that means two things will eventually be wrong in one of them. Here it was wrong in both directions at once: as a key it was unregistered garbage; as the only spelling available it taught users and the migration to write garbage.

Four surfaces, no handshake

A notify option in this codebase lives on four surfaces that must agree: the defaults (DefaultNATSKVS — what validation accepts and mc admin config get displays), the help (HelpNATS — what mc admin config documents), the parser (GetNotifyNATS — what the server actually reads), and the migration (SetNotifyNATS — what upgrades write). Nothing ties them together. Three upstream feature PRs each updated the parser and the env plumbing, and each forgot the first two surfaces: