chore(oscap): re-pin fixture base-image digests - #173
Open
octo-sts-10[bot] wants to merge 1 commit into
Open
Conversation
octo-sts-2
Bot
force-pushed
the
update-ca-cert-b8d837841b88bfaa1a0fa827cbca8e2576418dd47c9fc4bb7f1f9d89c83111b9
branch
from
September 4, 2026 01:15
6297916 to
0f736cb
Compare
stevebeattie
added a commit
to stevebeattie/chainguard-dev-stigs
that referenced
this pull request
Sep 4, 2026
Review of chainguard-dev#174 raised that converting all 29 AddFile calls to PutFile removes the base-drift alarm from the entire fixture matrix at once: the ErrExists that fired when the base gained etc/ssl/openssl.cnf was crude, but it was the only thing that noticed. Afterwards nothing did, and the failure mode inverted from "CI breaks with a confusing error" to "a fixture quietly asserts less than its name claims". The suggested mitigation was to keep one AddFile as a canary. That works, but it re-arms the fragility inside a fixture whose job is a scan verdict, so a re-pin would turn the matrix red for a reason unrelated to the rule under test -- and it only watches whichever single path it happens to name. Asserting base composition directly covers the whole surface instead, and fails where the cause is rather than as a downstream verdict flip. Four premises, each row carrying the reason it matters so the failure explains itself: - Paths the fixtures require, because an existence-precondition op targets them (AppendFile on etc/shadow, CopyFile's source, Chown on var/log). - Paths whose ABSENCE gives a fixture its discriminating power -- the FIPS ssh drop-ins, etc/ssl/fipsmodule.cnf, the Java truststore pair that CertificateAudit tst:5 checks with none_exist. This is the silent class: gaining one of these leaves the fixture green. - PutFile targets are absent or regular files, never a directory or symlink. Not theoretical: the base ships etc/ssl/cert.pem and etc/ssl/certs/ca-bundle.crt as symlinks to ca-certificates.crt, so the next CA-bundle fixture that targets an alias hits ErrNotRegular. - No FIPS apk packages installed, which is the other half of what makes detect_openssl/fail_clean_no_fips a control. etc/ssl/openssl.cnf sits only in the third list, deliberately. It is the path that actually drifted, so pinning it present or absent would just re-create the bet PutFile removed; what must hold is that it stays a regular file. Verified by pointing the pin at chainguard-dev#173's digest: the check stays green across the re-pin, while planting a wrong row in each of the three path lists turns the matching subtest red with a message naming the path, its type and the dependent fixture. Only a registry pull is needed, not a container runtime or the datastream, so this runs in more environments than the matrix it protects. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Re-pins the digest-pinned FROM lines in tests/e2e/fixtures/*/Dockerfile and the pinned wolfi-base digest in the offline harness test (TestParseWolfiBaseRef) together, so the two can never drift out of sync and break the offline unit tests. Both stamp files CertificateAudit reads were checked first, on cgr.dev/chainguard/jre:latest: the CA bundle matches /etc/ssl/certs/.ca-certificates.crt.sha256 and the Java truststore matches /etc/ssl/certs/java/.cacerts.sha256. Image: cgr.dev/chainguard/wolfi-base:latest Digest: sha256:918a593b8268c222afd4e2c4f06860ac984e60719b4697e4c71d796bc8fcd042 Stamp image: cgr.dev/chainguard/jre:latest CA SHA: b8d837841b88bfaa1a0fa827cbca8e2576418dd47c9fc4bb7f1f9d89c83111b9 Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
octo-sts-2
Bot
force-pushed
the
update-ca-cert-b8d837841b88bfaa1a0fa827cbca8e2576418dd47c9fc4bb7f1f9d89c83111b9
branch
from
September 5, 2026 01:16
0f736cb to
d438fdf
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixture Base-Image Update
Re-pins two values that must stay in lockstep:
FROM cgr.dev/chainguard/wolfi-base:latest@sha256:...line inevery
tests/e2e/fixtures/*/Dockerfile.pinnedwolfi-base digest constant asserted byTestParseWolfiBaseRefintests/oscap-offline/internal/scan/fixtures_test.go.If these drift (e.g. Dependabot bumps the fixture digest without the
test pin following), the offline harness unit tests break. This
workflow is the authoritative update point for both together;
TestParseWolfiBaseRefwas run against the updated tree before thisPR was opened.
CertificateAudit itself no longer pins any hash — the OVAL reads each
expected digest from the stamp file shipped beside the file it
describes inside the scanned image
(
/etc/ssl/certs/.ca-certificates.crt.sha256, and on Java images/etc/ssl/certs/java/.cacerts.sha256). TheVerify trust-store stamp filesstep above asserts both are present and agree, usingcgr.dev/chainguard/jre:latestbecause it carries both, so an imagethat dropped one would fail this run rather than silently red the
E2E CertificateAudit assertions.
cgr.dev/chainguard/wolfi-base:latestsha256:918a593b8268c222afd4e2c4f06860ac984e60719b4697e4c71d796bc8fcd042cgr.dev/chainguard/jre:latestsha256:59e006e485d73c0d36d58e9d3702f9c29971b368f1c4fa03c95be2d5b0cb37a7b8d837841b88bfaa1a0fa827cbca8e2576418dd47c9fc4bb7f1f9d89c83111b9truetrue