codetruss 0.2.57

[DeliriumPulse]

Points the formula at the v0.2.57 release archive.

url    https://github.com/CodeTruss/codetruss-cli/releases/download/v0.2.57/codetruss-cli-0.2.57.tgz
sha256 533bd51c59e88febe5a3a1df88c0fcb3e6966970280017c7b84efb63a421ce9f

That digest was measured off the downloaded release asset, not copied from the release notes, and the URL written above was fetched independently with curl and cmpd against it. The asset is byte-identical to public/downloads/codetruss-cli-0.2.57.tgz in the monorepo, to the bytes codetruss.com serves, to the site's latest pointer, and to the archive rebuilt independently in the mirror from its own lockfile — five copies, all cmp clean.

gh attestation verify codetruss-cli-0.2.57.tgz --repo CodeTruss/codetruss-cli passes — the command was derived from attestationCommand() in packages/cli/scripts/release-metadata.mjs rather than retyped, and matches the attestationCommand field the live manifest publishes. It was run with --format json rather than trusting a bare exit code, so the subject it actually verified (codetruss-cli-0.2.57.tgz, digest 533bd51c…) and the signer identity (https://github.com/CodeTruss/codetruss-cli/.github/workflows/release.yml@refs/tags/v0.2.57, issuer token.actions.githubusercontent.com) are on the record.

The release carries all three attestations:

predicate	subject	how confirmed
https://slsa.dev/provenance/v1	codetruss-cli-0.2.57.tgz @ 533bd51c…	gh attestation verify --format json
https://cyclonedx.org/bom	codetruss-cli-0.2.57.tgz @ 533bd51c…	gh attestation verify --predicate-type … --format json, CycloneDX 1.6, 5 components
https://in-toto.io/attestation/release/v0.2	pkg:github/CodeTruss/codetruss-cli@v0.2.57, tag object 0ec9954f…, plus all three release assets by digest	attestations API — gh 2.85 exits 1 on this predicate because it is signed by dotcom.releases.github.com, not an Actions OIDC identity

That last row was confirmed rather than assumed: the certificate's SAN reads URI:https://dotcom.releases.github.com, which is exactly why the gh path cannot verify it.

The exit 0 is not vacuous. The same cmp against 0.2.55 — the version this formula pointed at until now — exits 1. gh attestation verify was checked against a tampered copy of the archive (one appended NUL), against the pre-transfer DeliriumPulse/codetruss-cli slug, and against an unrelated repository; all three exit 1, the attestations API returns non-zero for the tampered digest, and the release-predicate query for the 0.2.55 tag object returns pkg:github/CodeTruss/codetruss-cli@v0.2.55, not 0.2.57.

Nothing else changes. .github/workflows/test.yml derives the expected version from brew info rather than a literal, so it needs no edit; the version assertion in CI is what proves the installed binary matches the formula.

What 0.2.57 carries

Both changes are false-positive fixes — for a tool whose output is a security verdict, the failure mode that costs the most trust.

This release supersedes 0.2.56, which was merged but never released — no tag, no GitHub release, no formula bump. That has precedent (0.2.42, 0.2.47 through 0.2.49, and 0.2.54 are all merged-but-unreleased). It is not retroactively released; its change ships inside these bytes.

0.2.56 — Firebase web API keys are no longer reported as committed credentials. A VITE_/NEXT_PUBLIC_-prefixed key, and a Firebase config object passed straight to initializeApp({…}), are published to every visitor by design. Reporting them was CRITICAL and HIGH noise respectively, and these were the last two CRITICAL false positives on the ten-repo benchmark corpus.

0.2.57 — an error-code enum is no longer three leaked passwords. A value that merely spells out its own key (IncorrectEmailPassword = "incorrect-email-password") carries nothing the identifier beside it did not. The exemption is now the relation between value and key rather than the shape of the value, so password = "correct-horse-battery-staple" is still reported. Repo-supplied scope globs are also bounded (512 chars, 16 brace groups, 1,024 expansions) before reaching the matcher, and rejected by name rather than truncated.

The downgrade is deliberately narrow, and the narrowness is pinned by a fixture rather than by prose: a server-side Google API key in the same .env, under a name the build tool does not publish, is asserted to stay CRITICAL.

receipt.ts was also split into receipt-markdown.ts, receipt-store.ts and receipt-verify.ts behind a facade. dist/cli.cjs moves 828,065 → 834,037 bytes (+5,972), 32 changed lines of 296. Receipts stay on local-registry-v5, and every frozen profile renderer (v1 through v5) pins an unchanged SHA-256 — packages/cli/test/verify-receipt.test.ts is byte-identical between the 0.2.55 and 0.2.57 source trees, which matters more than usual given the file split.

Verified against the published archive, not a local build

Installed into a dedicated npm --prefix and invoked by absolute path — this machine also carries a stale global codetruss (0.2.28, from Homebrew) that must not be allowed to answer:

• codetruss --version → codetruss 0.2.57 (the stale global still answers codetruss 0.2.28, so the absolute path is doing real work)
• the installed dist/cli.cjs is byte-identical to the one inside the downloaded release archive, and cmps non-zero against 0.2.55's bundle
• README.md inside the installed package reads local-registry-v5 and 15-pass, matching LOCAL_ANALYSIS_PROFILE.id in source — the 0.2.54 derivation guard holds in these bytes
• a freshly signed receipt reads Profile: `local-registry-v5` and codetruss verify latest accepts its signature; flipping one word inside the signed receipt makes it exit 3 with Markdown receipt does not match the signed JSON, so the acceptance is not vacuous
• the shipped acceptance suite, run against the published bundle, printed reproduced 6 adjudicated verdicts over 4 fixtures

The acceptance check was demonstrated red in both directions before being trusted. Emptying PUBLISHABLE_CREDENTIAL_TYPES (reverting the 0.2.56 fix) reports .env.production:6 … severity CRITICAL, expected INFO and src/firebase.ts:8 … severity HIGH, expected INFO; widening PUBLISHABLE_ENV_BINDING to match any binding trips the negative control with MAPS_SERVER_KEY … severity LOW, expected CRITICAL. So it fails if the fix is missing and if the fix is too broad. It ran green in all six upstream CI contexts that execute the test suite, and in the tag-triggered release job that produced this archive.

One note, not a wart

The upstream ci.yml still gates its Test step on matrix.node != '20.9.0', so the acceptance script runs in six of the nine required contexts — confirmed from the job step conclusions (Test: skipped on Node 20.9.0, Test: success on Node 24), not inferred. The 0.2.55 changelog claimed "all nine"; that count is stated correctly in the 0.2.57 release PR rather than repeated.

🤖 Generated with Claude Code