GitHub user Ma77Ball edited a comment on the discussion: Recent changes about MinIO
# Replace MinIO in CI and deployments: official images removed from Docker Hub ## Summary The official `minio/minio` and `minio/mc` images are gone from Docker Hub. Only unmaintained legacy mirrors remain, and the last community build ships an unpatched high-severity CVE. Texera CI pulls MinIO as the S3 store behind LakeFS and Iceberg, so fresh runs fail at image pull. We need to pick a replacement. **RustFS** and **SeaweedFS** have been suggested; **Garage**, **Silo**, and **Chainguard's MinIO rebuild** are also compared below. ## What happened upstream - **Oct 2025** MinIO Community Edition went "source-only": no more prebuilt binaries or images. The final published image contains **CVE-2025-62506** (restricted service accounts can escalate to unrestricted ones), which the maintainers declined to patch. - **Dec 2025** Project entered maintenance mode: no new features, no PR reviews, security fixes case-by-case only. - **Apr 2026** Upstream repo archived. Docker Hub removed `minio/minio` and `minio/mc` entirely; all tags return 404 / `pull access denied`. `bitnami/minio` is also gone. Quay still serves frozen, unmaintained tags. ## Impact on Texera MinIO appears in four places: 1. **Compose/K8s stack** S3 blockstore behind LakeFS (versioned dataset collections). 2. **Iceberg storage** the Lakekeeper REST catalog writes table data to the same endpoint. 3. **Local dev** `bin/local-dev.sh` starts MinIO on `:9000`. 4. **CI** GitHub Actions brings up the stack; `docker pull minio/minio:<tag>` now fails and breaks every fresh run. Why pinning a legacy tag or unofficial mirror is not acceptable: - The latest images carry CVE-2025-62506 with no fix coming. - Unofficial mirrors are unaudited and can introduce a supply-chain risk for an Apache project. - Building from an archived AGPL repo makes us maintainers of dead code. One thing in our favor: everything talks to MinIO through the **generic S3 API** (LakeFS, Lakekeeper, AWS SDKs). We are not coupled to MinIO itself. Requirements for a replacement: S3 multipart upload + path-style addressing, single-container deployment, healthcheck endpoint, static key config, amd64/arm64 images, and an ASF-friendly license (Apache-2.0 preferred; AGPL is a complication). ## Candidates | | License | S3 coverage | Maturity | Drop-in? | Main upside | Main risk | |---|---|---|---|---|---|---| | **RustFS** | Apache-2.0 | Broad (multipart, versioning, policies, lifecycle, SSE); some Object Lock/encryption gaps | Young was alpha-labeled "not for production"; verify current status | Near MinIO-shaped config, web console included | Purpose-built MinIO successor, clean license, single container | Stability; young project may churn | | **SeaweedFS** | Apache-2.0 | Solid core via S3 gateway; some IAM/policy edge cases differ | Production-proven since ~2015; O(1) reads at any object count | No master + volume (+ filer + gateway) processes, new config | Most mature Apache-2.0 option | Heavier than a CI blockstore needs; larger migration | | **Garage** | AGPL-3.0 | Core ops only; versioning/lifecycle incomplete | Moderate; small codebase | No different config model | Tiny footprint (~1 GB RAM), dead-simple ops | AGPL + gaps that LakeFS may hit | | **Silo** (`pgsty/silo`, community MinIO fork) | AGPL-3.0 | Identical to MinIO: same `MINIO_*` vars, `mc`, healthcheck, on-disk format | Fork is new; codebase is MinIO's | **Yes, image-name swap only** | Zero-effort fix; reuses existing data volumes | Fork longevity; AGPL; inherits MinIO's architecture | | **Chainguard MinIO** | AGPL-3.0 upstream | Identical to MinIO at freeze | Rebuilt from source, CVE-patched, SLSA L3 | **Yes image-name swap only** | Immediate, security-patched, free tier | Depends on Chainguard's free tier; upstream frozen, no new features | Also considered and rejected: **Ceph RGW** (most battle-tested S3, but massive operational overkill for a CI blockstore) and **LocalStack S3** (fine for mocking, but dev and single-node deployments need a real store). ## Proposed plan **Step 1: unblock CI (1 PR, no config changes):** - [ ] Swap the image in compose/CI to a CVE-patched drop-in: `pgsty/silo` or Chainguard's MinIO. Keep service name, ports, `MINIO_*` env, and `mc ready` healthcheck untouched. - [ ] Pin by digest, not `:latest`. - [ ] Update `bin/local-dev.sh` to the same image. **Step 2: pick the long-term store:** - [ ] Spike branch: run the full LakeFS → Lakekeeper → Iceberg path against **RustFS** and **SeaweedFS**. Test multipart upload, path-style access, presigned URLs, and Iceberg's conditional-write commit path. - [ ] Confirm RustFS has exited alpha and check its release cadence and multi-arch images. - [ ] Choose whichever Apache-2.0 option passes cleanly (RustFS if stable, else SeaweedFS) and migrate compose, K8s manifests, docs, and CI. **Before merging the long-term switch:** - [ ] Document a data migration path for existing deployments (`mc mirror` / `rclone` copy; Silo alone reuses MinIO volumes as-is). - [ ] Confirm ASF licensing position if any AGPL component remains referenced in compose files. ## Open questions 1. Has anyone run RustFS or SeaweedFS behind LakeFS in production or CI? 2. Any ASF policy concerns with compose files referencing an AGPL image (Silo) as an unbundled runtime dependency, even temporarily? 3. Should CI and local dev stay on the identical store, or is a lighter store acceptable for CI only? 4. Do we know of Texera deployments with existing MinIO data volumes that need an in-place migration story? ## References - MinIO source-only fallout: https://linuxiac.com/minio-with-yet-another-controversial-move/ - CVE-2025-62506 and rebuilt images: https://www.chainguard.dev/unchained/secure-and-free-minio-chainguard-containers - Docker Hub removal report: https://github.com/FiligranHQ/xtm-docker/issues/43 - Alternative comparisons: https://blog.elest.io/rustfs-vs-seaweedfs-vs-garage-which-minio-alternative-should-you-pick/ · https://iomete.com/resources/blog/evaluating-s3-compatible-storage-for-lakehouse GitHub link: https://github.com/apache/texera/discussions/3998#discussioncomment-18418445 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
