Feng Ruohang
fe6dc47804
The address MinIO attributes a request to is read from X-Forwarded-For,
X-Real-IP or RFC 7239 Forwarded, and never from the connection unless all
three are absent. It becomes aws:SourceIp and the audit remotehost field,
so any client that can reach the API port chooses the value an IpAddress
condition is evaluated against and the address every logged action is
attributed to.
MINIO_API_TRUSTED_PROXIES now selects who may make that claim:
unset the historical behaviour, unchanged
none no forwarded header is believed; the TCP peer wins
<CIDRs> believed only from listed peers, chains read right-to-left
Reading right-to-left is what makes an appending proxy safe: each hop
appends the peer it actually saw, so an entry a client injected can only
sit to the left of one a proxy wrote. The stock nginx recipe
$proxy_add_x_forwarded_for appends, which leaves the client's entry
left-most - exactly where the untrusted path reads - so a deployment with
no direct route to the API port was forgeable too.
_MINIO_API_XFF_HEADER is deliberately untouched, in semantics and in read
timing. Widening it to mean "trust nothing" was implemented and reverted:
it is the only part of this change that could alter a deployed
configuration, and the new variable expresses the same guarantee at no
compatibility cost. Upstream's TestXFFDisabled is retained verbatim.
Notes on the allow-list mode, all covered by tests:
- it must name proxies, not the subnet they sit in; listed entries are
skipped while walking, so a range covering clients lets them forge
- a cluster must list its own nodes, because MinIO forwards between
them and a client can force a hop via the ListObjectsV2 token
- loopback is trusted as a peer, not as a chain entry, so FTP and SFTP
keep attributing their sessions
- the node-to-node forwarder drops X-Real-IP and Forwarded from a peer
not entitled to have set them
- the walk scans the header in place and stops after 100 hops, so a
long chain costs neither allocation nor unbounded work
No behaviour change for any deployment that does not set the new
variable: the untrusted path is a verbatim copy of the previous function
body, differentially verified against it over ~5.1M header combinations.
The LDAP STS allow-list now shares the list parser as pure code motion,
verified identical across every combination of 37 allow-list values and
21 peer addresses.
Co-authored-by: ChatGPT <noreply@openai.com>
Co-authored-by: Claude <noreply@anthropic.com>
Silo
A conservatively maintained MinIO fork
Security maintenance, versioned release artifacts, and operational continuity for existing deployments.
中文 · Documentation · Releases · Container Images · Security
Important
Silo is an independent, community-maintained fork of the open-source MinIO server, published by Pigsty from
pgsty/minio. It is not affiliated with, endorsed by, or sponsored by MinIO, Inc. “MinIO” is used only to identify the upstream project and compatibility lineage.
Overview
Silo maintains one downstream release line based on MinIO RELEASE.2025-12-03T12-00-00Z. It provides maintained builds and release artifacts for existing MinIO-compatible deployments after upstream community distribution ended.
Pigsty uses this fork for object storage, including PostgreSQL backups.
Maintenance Policy
The active release line covers:
- build and dependency maintenance;
- applicable security fixes and advisories;
- focused fixes for reproducible defects;
- versioned binaries, packages, checksums, and multi-architecture images;
- the web console, client, documentation, and Pigsty integration.
Changes are kept narrow and tested where practical. Maintenance is best effort; no response, remediation, or release schedule is guaranteed.
Out of scope
- a separate product roadmap, new storage engine, or speculative S3 features;
- broad rewrites or changes that materially expand the downstream delta;
- historical releases or multiple support branches;
- commercial support, SLAs, 24×7 coverage, or SUBNET access;
- deployment design, access control, monitoring, backup, or recovery.
Compatibility
Silo aims to preserve:
- the
minioexecutable andgithub.com/minio/miniomodule path; - MinIO-compatible S3 APIs, configuration, environment variables, and CLI conventions;
RELEASE.YYYY-MM-DDTHH-MM-SSZtags, container entrypoints, and common deployment workflows.
Compatibility is a goal, not a guarantee. Security fixes may change behavior. Treat each release as a downstream upgrade: pin versions, review release notes and security advisories, keep a rollback path, and test before production use.
Release Artifacts
| Artifact | Location |
|---|---|
| Source | github.com/pgsty/minio |
| Container image | pgsty/minio, multi-arch for linux/amd64 and linux/arm64 |
| Server binaries | GitHub Releases for Linux, macOS, and Windows on amd64 and arm64 |
| Linux packages | RPM, DEB, and APK artifacts, also distributed through the Pigsty repository |
| Client | pgsty/mc, bundled in the container as mcli with an mc compatibility alias |
| Console | Maintained georgmangold/console fork, embedded in the server build |
| Documentation | English, Chinese, and pgsty/minio-docs |
| Security record | SECURITY.md, VULNERABILITY_REPORT.md, and fork advisories |
Quick Start
For local evaluation:
mkdir -p data
export MINIO_ROOT_USER=minioadmin
export MINIO_ROOT_PASSWORD=change-me-long-password
docker run -d --name silo \
-p 9000:9000 \
-p 9001:9001 \
-e MINIO_ROOT_USER \
-e MINIO_ROOT_PASSWORD \
-v "$PWD/data:/data" \
pgsty/minio:latest server /data --console-address ":9001"
Open the console at http://localhost:9001; the S3 API listens on http://localhost:9000.
The image includes the compatible client as mcli:
docker exec silo mcli alias set local http://127.0.0.1:9000 \
"$MINIO_ROOT_USER" "$MINIO_ROOT_PASSWORD"
docker exec silo mcli mb local/demo
docker exec silo mcli ls local
Warning
For production, pin a release, use unique credentials and TLS, monitor the service, keep independent backups, and test recovery.
Build the server from source:
go build -o minio .
./minio --version
Deployment: Silo documentation · Pigsty MinIO module
Security
Security fixes target the active master branch and are recorded in the advisory log. Report vulnerabilities privately as described in SECURITY.md and VULNERABILITY_REPORT.md. Report issues that also affect upstream MinIO there as well.
Contributing
Useful contributions include security and dependency updates, reproducible bug fixes, tests, release automation, packaging, and documentation.
Issues and pull requests should include the affected version, reproduction steps, impact, expected behavior, tests, and compatibility notes. Discuss large changes in an issue first.
Background
This project was created in response to changes in the upstream community distribution and maintenance model. The maintainer’s analysis, alternatives considered, and early maintenance record are documented below:
| Essay | Subject |
|---|---|
| MinIO Is Dead | Changes to the upstream project and distribution model |
| MinIO Is Dead, Long Live MinIO | Establishing the fork and its release pipeline |
| Two months into maintaining a MinIO fork | Initial security and maintenance work |
License and Trademark
The server remains licensed under the GNU Affero General Public License v3.0. See CREDITS for upstream authorship and attribution. MinIO is a trademark of MinIO, Inc. Silo and pgsty/minio are independent community efforts and are not affiliated with or endorsed by MinIO, Inc.