CI pipeline blocked: `minio` returns `unauthorized` on pull

[matamadio]

Summary

The Continuous integration workflow (.github/workflows/ci.yaml) has started failing at the make check step, before any linting or tests actually run. The failure is a container pull error, not a code or test failure, and it is not caused by any change in this repository.

Where it happens

• Workflow: .github/workflows/ci.yaml, step Lint (run: make check)
• make check invokes docker compose -f docker-compose-test.yaml run --rm ..., which needs to start the testminio and testminio-client services before the check container can run.
• Those services are defined in docker-compose-test.yaml:
  • testminio → image: quay.io/minio/minio
  • testminio-client → image: quay.io/minio/mc

Error log

testminio Error unauthorized: access to the requested resource is not authorized
testminio-client  Interrupted
Error response from daemon: unauthorized: access to the requested resource is not authorized
make: *** [Makefile:70: check] Error 1
Error: Process completed with exit code 2

Root cause

MinIO has restricted anonymous/public pulls of its official container images across major registries, in quick succession:

• Docker Hub stopped serving minio/minio anonymously around 2026-09-12.
• quay.io/minio/minio and quay.io/minio/mc followed, returning 401 unauthorized for anonymous pulls starting around 2026-09-24.

This is an external, vendor-side change, not specific to this repository. Numerous unrelated open-source projects hit the identical unauthorized: access to the requested resource is not authorized error on the same images in the same window (e.g. quay.io/minio/minio, quay.io/minio/mc), confirmed via multiple independent GitHub issues opened in the past two weeks reporting the same registry response.

Impact

• Documentation site (docs/, deployed via .github/workflows/gh-pages.yml) is unaffected — that workflow does not depend on docker-compose-test.yaml or MinIO.
• Currently live application (thinkhazard.org / int.thinkhazard.org) is unaffected in real time — MinIO here is only a test-environment stand-in for S3 storage, not a runtime dependency of the deployed app.
• New application deployments are blocked: ci.yaml gates docker-push (the step that actually publishes a new application image) on check → test → build all succeeding. Since check fails at the MinIO pull stage, no new code change can currently reach production through this pipeline until this is resolved.

Suggested next steps

No settled community-wide fix exists yet, since the lockdown is only days old at time of writing. Options to evaluate once ready to act:

1. Mirror the required MinIO images into a registry we control (e.g. GHCR under the GFDRR org, or Docker Hub) and repoint docker-compose-test.yaml at that mirror.
2. Replace MinIO in the test stack with an alternative S3-compatible test double, if the test suite only needs basic S3 API compatibility.
3. Monitor the situation in case MinIO restores anonymous access or publishes an official alternative distribution channel.

References

• docker-compose-test.yaml, lines 48–56 (testminio, testminio-client service definitions)
• .github/workflows/ci.yaml, Lint step
• Makefile, check target (line 68)