Dockerfile pin guard checks agreement between refs, not that they are pinned #51

New Issue

2026-09-04T12:07:51+02:00

clawbot commented

2026-09-04 12:07:51 +02:00

Surfaced during the independent review of PR #50. It is pre-existing — behaviour is identical before and after 337b319, so it was correctly out of scope for that PR — but it is a real gap and there is no automated enforcement of it anywhere in the repo.

Problem

The lint-image guard verifies that the two image references agree with each other. It does not verify that they are pinned. Two matching tag-only refs (no @sha256:) pass the guard cleanly.

That means the guard cannot catch the failure mode REPO_POLICIES.md:22-28 actually cares about: an unpinned base image. It only catches the two refs drifting apart from one another.

Why it matters

Unpinned image references are an automatic policy FAIL in review, but nothing in CI or in script/ detects them. The one mechanism that looks like it enforces pinning does not.

Definition of done

The guard rejects any image reference in the Dockerfile that lacks an @sha256: digest, independently of whether the two references agree.
Existing agreement checking is preserved — both properties are enforced, not one traded for the other.
A test proves the new rejection by mutation: introduce a tag-only-but-consistent pair and show the guard exits non-zero. Reading the script is not sufficient evidence.
The existing seven agreement-failure behaviours still fail correctly (digest-only disagreement, one file mangled, both files mangled, file deleted, one-sided tag, two differing tags, duplicate reference).
docker build --no-cache . passes.

Filed unassigned for triage.

Surfaced during the independent review of [PR #50](https://git.eeqj.de/sneak/sfdupes/pulls/50). It is **pre-existing** — behaviour is identical before and after `337b319`, so it was correctly out of scope for that PR — but it is a real gap and there is no automated enforcement of it anywhere in the repo. ## Problem The lint-image guard verifies that the two image references agree with each other. It does not verify that they are *pinned*. Two matching tag-only refs (no `@sha256:`) pass the guard cleanly. That means the guard cannot catch the failure mode `REPO_POLICIES.md:22-28` actually cares about: an unpinned base image. It only catches the two refs drifting apart from one another. ## Why it matters Unpinned image references are an automatic policy FAIL in review, but nothing in CI or in `script/` detects them. The one mechanism that looks like it enforces pinning does not. ## Definition of done 1. The guard rejects any image reference in the Dockerfile that lacks an `@sha256:` digest, independently of whether the two references agree. 2. Existing agreement checking is preserved — both properties are enforced, not one traded for the other. 3. A test proves the new rejection by mutation: introduce a tag-only-but-*consistent* pair and show the guard exits non-zero. Reading the script is not sufficient evidence. 4. The existing seven agreement-failure behaviours still fail correctly (digest-only disagreement, one file mangled, both files mangled, file deleted, one-sided tag, two differing tags, duplicate reference). 5. `docker build --no-cache .` passes. Filed unassigned for triage.

clawbot commented

2026-09-05 11:32:54 +02:00

Closed at sneak's instruction, 2026-09-05: this was opened by an agent running on another machine outside the managed fleet, under superseded rules. Reopen if the content is wanted.

Model: fable-5-1

Closed at sneak's instruction, 2026-09-05: this was opened by an agent running on another machine outside the managed fleet, under superseded rules. Reopen if the content is wanted. Model: fable-5-1

clawbot closed this issue

2026-09-05 11:32:54 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/sfdupes#51