Skip to content

chore(oscap): re-pin fixture base-image digests - #173

Merged
stevebeattie merged 1 commit into
mainfrom
update-ca-cert-b8d837841b88bfaa1a0fa827cbca8e2576418dd47c9fc4bb7f1f9d89c83111b9
Sep 16, 2026
Merged

chore(oscap): re-pin fixture base-image digests#173
stevebeattie merged 1 commit into
mainfrom
update-ca-cert-b8d837841b88bfaa1a0fa827cbca8e2576418dd47c9fc4bb7f1f9d89c83111b9

Conversation

@octo-sts-10

@octo-sts-10 octo-sts-10 Bot commented Sep 2, 2026 •
edited by octo-sts-2 Bot
Loading

Copy link
Copy Markdown

Fixture Base-Image Update

Re-pins two values that must stay in lockstep:

  1. The FROM cgr.dev/chainguard/wolfi-base:latest@sha256:... line in
    every tests/e2e/fixtures/*/Dockerfile.
  2. The pinned wolfi-base digest constant asserted by
    TestParseWolfiBaseRef in tests/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;
TestParseWolfiBaseRef was run against the updated tree before this
PR 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). The Verify trust-store stamp files step above asserts both are present and agree, using
cgr.dev/chainguard/jre:latest because it carries both, so an image
that dropped one would fail this run rather than silently red the
E2E CertificateAudit assertions.

  • Image: cgr.dev/chainguard/wolfi-base:latest
  • Digest: sha256:3754b6da0e1ccdab0fe46abfdd7bbbba994b593c28149f6659fa6597f2261aeb
  • Stamp image: cgr.dev/chainguard/jre:latest
  • Stamp image digest: sha256:8aa094103d61c155c1ba3bc16880d52ce71924fd656efbfd379e215f39f35a03
  • CA SHA256: b8d837841b88bfaa1a0fa827cbca8e2576418dd47c9fc4bb7f1f9d89c83111b9
  • Fixtures changed: true
  • Test pin changed: true

@octo-sts-10 octo-sts-10 Bot added the automated pr This PR was opened by a bot label Sep 2, 2026
@stevebeattie stevebeattie mentioned this pull request Sep 3, 2026
Merged
@octo-sts-2
octo-sts-2 Bot force-pushed the update-ca-cert-b8d837841b88bfaa1a0fa827cbca8e2576418dd47c9fc4bb7f1f9d89c83111b9 branch from 6297916 to 0f736cb Compare September 4, 2026 01:15
stevebeattie added a commit to stevebeattie/chainguard-dev-stigs that referenced this pull request Sep 4, 2026
@stevebeattie @claude
Assert base-image composition directly, so re-pin drift stays loud
25c9bfb 
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>
@octo-sts-2
octo-sts-2 Bot force-pushed the update-ca-cert-b8d837841b88bfaa1a0fa827cbca8e2576418dd47c9fc4bb7f1f9d89c83111b9 branch from 0f736cb to d438fdf Compare September 5, 2026 01:16
@octo-sts
octo-sts Bot force-pushed the update-ca-cert-b8d837841b88bfaa1a0fa827cbca8e2576418dd47c9fc4bb7f1f9d89c83111b9 branch from d438fdf to b0a9815 Compare September 10, 2026 16:39
@octo-sts-2
octo-sts-2 Bot force-pushed the update-ca-cert-b8d837841b88bfaa1a0fa827cbca8e2576418dd47c9fc4bb7f1f9d89c83111b9 branch 3 times, most recently from e28fc4b to 32c9bc5 Compare September 15, 2026 01:21
@octo-sts-10
octo-sts-10 Bot force-pushed the update-ca-cert-b8d837841b88bfaa1a0fa827cbca8e2576418dd47c9fc4bb7f1f9d89c83111b9 branch from 32c9bc5 to e48a820 Compare September 15, 2026 23:28
stevebeattie added a commit that referenced this pull request Sep 16, 2026
@stevebeattie @claude
Add an upsert overlay op so fixtures survive base-image re-pins
06b8d11 
The offline matrix broke on #173, the daily base-image re-pin: every
detect_openssl fixture failed with

    overlay apply: adding "etc/ssl/openssl.cnf": path already exists

before any scan ran. The newer wolfi-base ships /etc/ssl/openssl.cnf, which
the previously pinned image did not — confirmed by inspecting both: 0
occurrences at 7e62cecd, 1 at 103eb3f4.

The cause is that no overlay op could express what these fixtures want.
AddFile requires the path to be absent, ReplaceFile and AppendFile require it
to be present. So a fixture had to bet on whether the base image shipped a
path, and the bet expired silently whenever the base was re-pinned. Nothing
about the datastream or the checks was wrong; the End-to-end scan, mirror
check and sidecar guard all passed on that PR.

Add PutFile, which replaces an existing entry's content in place — keeping its
header and position — or creates one if absent. mode/uid/gid apply only on
creation, since a fixture replacing content is not usually restating
permissions.

Move all 29 AddFile calls in the fixture matrix onto it. Every one of them
means "this file holds this content"; none was relying on the absence
precondition for its meaning. The fixtures that do test absence express it by
*omitting* the file — fail_missing_ssh_fips_conf leaves the drop-ins out,
fail_java_missing_stamp adds a truststore and no stamp — so that behaviour is
unchanged. AddFile stays for cases where the base gaining a path should be a
loud failure rather than absorbed, and remains in use by CopyFile and PutFile.

Verified causally, not just by the suite going green:

  - against the base #173 pins, the converted fixtures pass, and reverting
    them to AddFile reproduces the exact "path already exists" error;
  - against the base on main, they pass too, so this is not a swap of one
    bet for the other;
  - full matrix green at 47 rows, 11 of them detect_openssl, 0 failures;
    gofmt/vet clean and the mirror check unaffected.

TestPutFile covers both directions plus the property that motivated it: the
same op applies cleanly whether or not the base ships the path.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@stevebeattie @github-actions
chore(oscap): re-pin fixture base-image digests
dfb192d 
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:3754b6da0e1ccdab0fe46abfdd7bbbba994b593c28149f6659fa6597f2261aeb
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
octo-sts-2 Bot force-pushed the update-ca-cert-b8d837841b88bfaa1a0fa827cbca8e2576418dd47c9fc4bb7f1f9d89c83111b9 branch from e48a820 to dfb192d Compare September 16, 2026 16:11
@stevebeattie
stevebeattie merged commit 20606ef into main Sep 16, 2026
8 checks passed
@stevebeattie
stevebeattie deleted the update-ca-cert-b8d837841b88bfaa1a0fa827cbca8e2576418dd47c9fc4bb7f1f9d89c83111b9 branch September 16, 2026 16:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@stevebeattie stevebeattie stevebeattie approved these changes

Assignees

No one assigned

Labels

automated pr This PR was opened by a bot

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@stevebeattie