Goal and scope
Advance the independently published MinIO image to 0.17.3 so the next publication carries fixes that are already on main. Non-goals: no Phlo or Python plugin version change, no publication (dispatching publish-minio.yml stays a separate maintainer action), and no release.
Why: the nightly Container Rescan has failed since 11 October.
- v0.18.0 pins
phlo-minio:0.17.1(sha256:f2592929…). It was published on 9 October by apublish-minio.ymlrun that had nosignjob (#1102 added signing on 10 October), so cosign 3.0.5 finds no signatures. It also has one fixable CRITICAL and several fixable HIGH findings. phlo-minio:0.17.2(sha256:31400025…) is signed and verifies, but still has 3 fixable HIGH findings: CVE-2026-116587 (go-jose; #1207 fixed the Dockerfile but nothing was published) and CVE-2026-92392 (Alpine curl, fixed in 8.23.0-r0).
Change map and risk
Mechanical only: every phlo-minio:0.17.2 pin becomes 0.17.3 (service YAMLs, both support manifests, CI workflows, integration fixtures, docs, and the README version notes). Same file set as #1173, plus the wap-failure-lab demo script. The Dockerfile is unchanged.
Ordering risk: integration jobs that pull 0.17.3 instead of building from source will fail until the image is published. Dispatch publish-minio.yml on main right after merging.
Verification
-
Built the
mainDockerfile locally and scanned it with Trivy 0.76.1: Alpine 0 findings;minioandmcbinaries 0 HIGH/CRITICAL (LOW=2, MEDIUM=3, UNKNOWN=6).container_security.py apply-policyexits 0. Image has curl/libcurl 8.23.0-r0. -
With that build tagged
0.17.3:pytest packages/phlo-minio/tests→ 50 passed (includes the Docker migration test). -
Support-manifest, workflow and tooling tests → 238 passed.
make checkstatic stages (support manifest, version drift, lint, typecheck, docs) pass. -
Not checked: a multi-arch build, or a publish to GHCR.
-
Not a code fix; this is a version-pin advance. The container policy scan is the regression gate.
Recovery and maintainer decisions
Revert restores the 0.17.2 pins. A published 0.17.3 tag is immutable and stays. Publication needs the maintainer to dispatch gh workflow run publish-minio.yml --repo phlohouse/phlo --ref main. The rescan stays red until a Phlo release pins 0.17.3 and the rebuilt phlo-api/phlo-dagster images (uv 0.13.4).
Activity
302
phlo-agent[bot]9h agoReviewed f595bdf. No blocking findings.
The pin sweep is consistent: both support manifests (byte-identical), the minio and minio-setup service definitions, CI/integration/nightly workflows, the tooling assertions that read them, docs/contributing/testing-gates.md, and the WAP demo all move to 0.17.3. publish-minio.yml takes the tag from registry/support/v1.json, so the post-merge dispatch builds and signs 0.17.3 rather than reusing 0.17.2.
The security basis checks out. The commit that introduced the 0.17.2 pins pinned github.com/go-jose/go-jose/v4@v4.1.4; this head pins v4.1.6, the patched version in GHSA-mgcc-cww5-fp2q. Alpine v3.24 main carries curl 8.23.0-r0, and the runtime stage runs apk upgrade with no-cache-filters: runtime in both build paths, so a publish re-resolves the OS packages.
PR checks do not depend on the unpublished tag: the integration lanes build the image from source and share it as an artifact. Outside CI, the demo script, the delta compose fixture and local runs of the container-backed tests do resolve the tag from GHCR, so they only work after publication, as the description says.
Non-blocking: run_integration.py:142 hardcodes the tag while MINIO_IMAGE carries the same value in CI. If those drift, the storage suite would pull a stale published image after the job verified the artifact's image ID; reading MINIO_IMAGE (with the tag as fallback) would remove that failure mode.
Remaining validation: publish 0.17.3 on main (multi-arch build, digest scan, cosign), then confirm the rescan scans it. The nightly stays red until a Phlo release pins 0.17.3, because v0.18.0's manifest still points at unsigned 0.17.1. At review time the check suite for f595bdf was still running (integration lanes queued); no failing check had been reported.
Architecture
Data flow
No data-flow sequence changed in this PR.
Review
✨ Nothing flagged · reviewed
f595bdf🪧 More tips
npx skills add coldteadotai/pr-lens, then tell your coding agent: "Diagram the change you just made with PR Lens and attach it to the pull request."npx @coldtea/pr-lens-cli analyze --base origin/mainon a branch, thennpx @coldtea/pr-lens-cli render .pr-lens/graph.json. Same lenses, your own model key, before the pull request existsrenderreads.github/pr-lens.ymland applies your renames, exclusions and lane pins at draw timegithub.comment.collapsed: truein.github/pr-lens.ymlto fold the comment behind one View architecture… row. Drawing still runs as beforegithub.draw: on-demandin.github/pr-lens.ymland PR Lens stops drawing pull requests on its own. Comment@pr-lens drawon a pull request when you want that one drawn.github/workflows/pr-lens.ymlwithcoldteadotai/pr-lens/packages/action@v0and your model provider's key as itsapi-keyto run PR Lens from your own CI. Any/chat/completionsendpoint worksgithub.description: falsein.github/pr-lens.ymlto stop PR Lens adding buttons to your PR descriptionsThanks for using PR Lens! It's free for OSS. If it helped, a star helps other teams find it.