Skip to main content
← Back to list
01Issue
BugOpenSwamp CLIPublic
AssigneesNone

Relationships

#2281 ci: configIntegrity check_hash treats a missing attestation key as a warning, so omission passes the merge gate

Opened by skunk-ape · 9/18/2026

Found while triaging swamp-club#2265, whose Related section asks for an audit of the trust chain for other instances of a missing signal being read as success. This is one, and it sits in CI - the one layer that issue identifies as independently run.

What happens

.github/workflows/ci.yml defines check_hash at lines 626-640. When the attestation does not contain the key being checked, it does this:

att_hash=$(jq -r "JQPATH // empty" attestation.json)
if [ -z "att_hash" ]; then
  echo "not in attestation" >> GITHUB_STEP_SUMMARY
  echo ":⚠️:Config integrity: LABEL not in attestation"
  warnings=warnings + 1
  return
fi

and the validation result at lines 688-698 exits non-zero only when errors is above zero:

if [ "errors" -gt 0 ]; then
  ... exit 1
elif [ "warnings" -gt 0 ]; then
  echo "Validation Passed with Warnings"
fi

So an attestation that simply omits a configIntegrity key produces a warning and validate-attestation still exits 0. validate-attestation is a required merge-gate check, so the PR merges.

Why it matters

configIntegrity is what proves the review prompts, workflows, skill scripts and CLAUDE.md used during local verification match the versions at the verified commit. Ten entries are checked (lines 652-662). A mismatched hash is an error and correctly fails. A missing hash is not - and missing is the cheaper of the two to produce, since the attestation is built locally by the same agent whose work is being gated. The check is therefore strict against corruption and permissive against omission, which is the wrong way round for a trust root.

The same logic at lines 636-640 treats a file that is absent at the commit as a warning too.

Suggested fix

Treat a missing attestation key as an error, not a warning. The set of configIntegrity keys is fixed and enumerated in the workflow itself, so there is no case where a key should legitimately be absent from a well-formed attestation. If backwards compatibility with older attestations is a concern, gate on the attestation schema version rather than on the keys silent absence.

Consider also whether "Validation Passed with Warnings" should gate the merge at all, given every remaining warning path in this job is about the trust root.

Note

Adding a new configIntegrity entry is currently a no-op for enforcement, which is directly relevant to the fix planned for swamp-club#2265 - that plan adds a checksum entry for an extracted verdict script and would otherwise be relying on an entry that cannot fail.

02Bog Flow
◉OPEN○TRIAGED○IN PROGRESS○SHIPPED

Open

9/18/2026, 4:44:33 PM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.