Issue 114: quay.io disabled anonymous pulls for minio's own images #102

2026-09-24T13:10:57Z

jschoubben commented

2026-09-24 13:10:57 +00:00

Found tonight checking minio before assigning it to novox. Both quay.io/minio/mc and the module's own pinned quay.io/minio/minio@sha256:14cea493... return a token with actions:[] and $disabled — anonymous pull disabled upstream, sometime after the 2026-09-20 rehearsal. Ruled out novox-side causes first (DNS, daemon.json, the auth handshake all fine).

Distinct from #064 (closed): that one was the mesh's build environment reaching a declared vendor image. This is the vendor disabling the image for everyone — a pinned digest doesn't protect against it.

Handing this off per the operator's request — minio is dropped from the active novox module queue for now, not blocking the rest of it. Checks pass.

Found tonight checking `minio` before assigning it to `novox`. Both `quay.io/minio/mc` and the module's own pinned `quay.io/minio/minio@sha256:14cea493...` return a token with `actions:[]` and `$disabled` — anonymous pull disabled upstream, sometime after the 2026-09-20 rehearsal. Ruled out `novox`-side causes first (DNS, `daemon.json`, the auth handshake all fine). Distinct from #064 (closed): that one was the mesh's build environment reaching a declared vendor image. This is the vendor disabling the image for everyone — a pinned digest doesn't protect against it. Handing this off per the operator's request — `minio` is dropped from the active `novox` module queue for now, not blocking the rest of it. Checks pass.

jschoubben added 1 commit 2026-09-24 13:10:57 +00:00

Issue 114: quay.io disabled anonymous pulls for minio's own images 17fb7c26d2

Found checking minio before assigning it on novox. Not a novox-side
problem - DNS, daemon.json and the auth handshake are all fine; quay.io's
own token for both quay.io/minio/mc and quay.io/minio/minio (the module's
own pinned server image) comes back with actions:[] and $disabled. Worked
four days ago at the 2026-09-20 rehearsal.

Distinct from issue 064: that one was about the mesh's build environment
reaching a declared vendor image. This is the vendor disabling the image
for everyone, which a declared, pinned digest does nothing to protect
against.

Checks pass.

jschoubben commented

2026-09-24 13:47:44 +00:00

Closing without merging — superseded by a much more thorough, and more correct, investigation that landed on main independently as issue 113 (same number I'd used here for a different, still-open issue — see PR #100, which needs renumbering as a result).

Their finding corrects mine: I read "actions":[] + "$disabled" on the anonymous token as quay.io disabling access. Issue 113 proved that's wrong with a control test — a deliberately invented, never-existing repository name in the same namespace returns the byte-identical response. The real cause is upstream deletion (MinIO withdrew the community server/client images entirely, confirmed via the registries' own APIs, 404 vs 200 on sibling repos), not an access policy. $disabled describes image signing and appears on every repository, including working ones.

Also: this report named the registry literally, seven times — a violation of hq's own rule against naming hosting providers. Issue 113's report avoids this correctly throughout.

Keeping this PR's history rather than deleting the branch, per hq's own "closed issues are never deleted" — but not merging a superseded, incorrect root-cause into the record.

Closing without merging — superseded by a much more thorough, and more correct, investigation that landed on `main` independently as issue **113** (same number I'd used here for a different, still-open issue — see PR #100, which needs renumbering as a result). Their finding corrects mine: I read `"actions":[]` + `"$disabled"` on the anonymous token as quay.io disabling access. Issue 113 proved that's wrong with a control test — a deliberately invented, never-existing repository name in the same namespace returns the byte-identical response. The real cause is upstream deletion (MinIO withdrew the community server/client images entirely, confirmed via the registries' own APIs, `404` vs `200` on sibling repos), not an access policy. `$disabled` describes image signing and appears on every repository, including working ones. Also: this report named the registry literally, seven times — a violation of hq's own rule against naming hosting providers. Issue 113's report avoids this correctly throughout. Keeping this PR's history rather than deleting the branch, per hq's own "closed issues are never deleted" — but not merging a superseded, incorrect root-cause into the record.

jschoubben closed this pull request

2026-09-24 13:47:48 +00:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#102