Follow-up from the exact-head review of #33.
Problem
The installer can rebuild missing managed images for the same immutable engine_ref, but the Dockerfiles still consume mutable base-image tags and mutable package indexes. Two builds of one reviewed engine commit can therefore yield different image IDs while carrying the same OCI revision label.
Acceptance criteria
- Pin every managed base image by digest.
- Lock or otherwise attest mutable package/module inputs used by both managed-image builds.
- Publish or record the reviewed image digests for each engine commit.
- Make convergence and rollback verify exact reviewed digests, not only the source revision label.
- Preserve deterministic missing-image recovery without weakening the fixed-engine trust boundary.
- Add tests that reject changed image content carrying the same engine revision.
Current safety boundary
#33 pins and verifies the reviewed source commit, labels both managed images with that exact revision, verifies the running controller provenance/environment, and scopes rebuilds to the managed candidate path. It does not claim bit-reproducible images; making that guarantee safely requires selecting and maintaining immutable upstream build inputs rather than guessing digests in #33.
Follow-up from the exact-head review of #33.
Problem
The installer can rebuild missing managed images for the same immutable
engine_ref, but the Dockerfiles still consume mutable base-image tags and mutable package indexes. Two builds of one reviewed engine commit can therefore yield different image IDs while carrying the same OCI revision label.Acceptance criteria
Current safety boundary
#33 pins and verifies the reviewed source commit, labels both managed images with that exact revision, verifies the running controller provenance/environment, and scopes rebuilds to the managed candidate path. It does not claim bit-reproducible images; making that guarantee safely requires selecting and maintaining immutable upstream build inputs rather than guessing digests in #33.