Skip to content

fix(governance): a stub Containerfile is not packaging - #537

Merged
hyperpolymath merged 1 commit into
mainfrom
fix/container-stub-detection
Jul 27, 2026
Merged

fix(governance): a stub Containerfile is not packaging#537
hyperpolymath merged 1 commit into
mainfrom
fix/container-stub-detection

Conversation

@hyperpolymath

Copy link
Copy Markdown
Owner

Follow-up to #534, which added sealed-container detection but accepted it on presence alone.

That reproduces the very fault this script exists to remove: #505 s predecessor accepted any *.scm as "Guix detected", and the Guix predicate was tightened for exactly that reason. The container branch was left untightened.

The problem

The estate scaffold ships a Containerfile template whose every install and build line is a commented # TODO: example — no active RUN, no ENTRYPOINT. It provides no environment at all, yet satisfied the gate.

Measured across hyper-repos + meta-repos:

count
stub Containerfiles (no active RUN/ENTRYPOINT/CMD) 17
real Containerfiles 43

So 17 repos were being reported compliant on the strength of an untouched template.

How it was found: while preparing to add Containerfiles to the 29 Nix-only repos that the 2026-06-01 retirement made non-compliant — i.e. that sweep was about to mass-produce artefacts satisfying a gate I already knew was weak. Better to tighten first.

The predicate

Deliberately cheap and syntactic: at least one active RUN / ENTRYPOINT / CMD. It cannot prove an image is useful, but it separates "someone filled this in" from "this is the untouched template" — the distinction actually available at gate time. A stub now warns and is treated as no packaging.

Red-teamed — six cases

case exit
stub Containerfile, post-cutoff 1 warns, does not pass
real Containerfile (RUN) 0
real Containerfile (ENTRYPOINT only) 0
stub + guix.scm 0 guix wins, no container warning
stub + flake.nix, nix retired 1 correctly non-compliant
only a commented-out RUN 1 not fooled by # RUN ...

bash -n clean.

🤖 Generated with Claude Code

#534 added sealed-container detection but accepted it on PRESENCE ALONE. That
reproduces the exact fault this script exists to remove: standards#505's
predecessor accepted any *.scm as "Guix detected", and the Guix predicate was
tightened for precisely that reason. The container branch was left untightened.

The estate scaffold ships a Containerfile template whose every install and
build line is a commented `# TODO:` example — no active RUN, no ENTRYPOINT. It
provides no environment whatsoever, yet satisfied the gate.

Measured 2026-07-27 across hyper-repos + meta-repos:
  stub Containerfiles (no active RUN/ENTRYPOINT/CMD):  17
  real Containerfiles:                                 43

So 17 repos were being reported compliant on the strength of an untouched
template. Found while preparing to add Containerfiles to the 29 Nix-only repos
the 2026-06-01 retirement made non-compliant — i.e. the sweep was about to mass
produce artefacts that pass a gate known to be weak.

The predicate is deliberately cheap and syntactic: at least one ACTIVE
RUN / ENTRYPOINT / CMD. It cannot prove an image is useful, but it separates
"someone filled this in" from "this is the untouched template", which is the
distinction available at gate time. A stub now warns and falls through to the
same treatment as no packaging at all.

Red-teamed — six cases, measured:
  stub Containerfile, post-cutoff        -> 1  warns, does not pass
  real Containerfile (RUN)               -> 0  ✅
  real Containerfile (ENTRYPOINT only)   -> 0  ✅
  stub + guix.scm                        -> 0  guix wins, no container warning
  stub + flake.nix, nix retired          -> 1  correctly non-compliant
  only a COMMENTED-OUT RUN               -> 1  not fooled by `#   RUN ...`

`bash -n` clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@sonarqubecloud

Copy link
Copy Markdown

@hyperpolymath
hyperpolymath merged commit 7221ffd into main Jul 27, 2026
23 of 25 checks passed
@hyperpolymath
hyperpolymath deleted the fix/container-stub-detection branch July 27, 2026 14:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant