Feng Ruohang c8590413fd fix: accept full object multipart completion without part checksums
CompleteMultipartUpload compared the per-part checksum taken from the
request body against the stored part checksum unconditionally, so a
client that sent only PartNumber and ETag for each part failed with
InvalidPart.

AWS S3 requires part level checksums in the completion body only for
composite checksum types. For full object types the client sends the
object level checksum in the request headers instead and does not retain
per-part values - that is the point of FULL_OBJECT. Reproduced with
boto3 1.43.58: it puts x-amz-checksum-crc32 on each UploadPart and the
full object checksum on the completion headers, but emits only ETag and
PartNumber in the completion body. A caller could only get such an upload
through by collecting the per-part checksums from the UploadPart
responses and echoing them back, which is exactly the bookkeeping
FULL_OBJECT exists to avoid and which no off-the-shelf SDK call does.
minio-go does echo them, which is why mc never hit this.

Treat the part checksum as optional when the upload declared a full
object checksum type and the client sent no part checksum at all. A part
carrying any checksum is still validated against the stored one -
including one sent under the wrong algorithm, which cannot match and is
rejected - composite uploads keep requiring a checksum for every part,
and the merged object checksum is still computed from the server stored,
upload time validated part checksums, never from client supplied values,
so integrity is unchanged.

Covered by API level tests over CRC32, CRC32C and CRC64NVME on both the
single drive and erasure backends, with guards for a wrong object
checksum, a wrong part checksum, a part checksum under another algorithm,
a mix of present and omitted part checksums, an absent object checksum,
and composite uploads still requiring every part checksum.

Fixes #31

Reported-by: Christophe Bornet <cbornet@users.noreply.github.com>

Co-authored-by: ChatGPT <noreply@openai.com>
Co-authored-by: Claude <noreply@anthropic.com>
2026-08-04 22:48:06 +08:00
2025-01-02 21:34:47 -08:00
2021-06-18 10:41:54 -07:00
2021-06-18 10:34:28 -07:00
2025-03-12 22:29:51 -07:00
2025-01-02 21:34:47 -08:00
2021-04-23 11:58:53 -07:00
2026-03-21 13:41:04 +08:00
2023-02-19 00:03:50 +05:30

Silo

A conservatively maintained MinIO fork
Security maintenance, versioned release artifacts, and operational continuity for existing deployments.

中文 · Documentation · Releases · Container Images · Security

GitHub Release Docker Pulls Go Version License

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 minio executable and github.com/minio/minio module path;
  • MinIO-compatible S3 APIs, configuration, environment variables, and CLI conventions;
  • RELEASE.YYYY-MM-DDTHH-MM-SSZ tags, 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 maintainers 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.

S
Description
No description provided
Readme AGPL-3.0 134 MiB
Languages
Go 98.8%
Shell 1%
Makefile 0.1%