fix(cosign): correct trust-list github org refs#96
Conversation
…, pgserve → namastexlabs)
The hardcoded TRUSTED_IDENTITIES regexes in src/cosign/trust-list.js
referenced two GitHub orgs that don't host the actual release workflows:
| publisher | trust-list regex | actual repo |
|---------------------|-----------------------------------|----------------------|
| @automagik/genie | github.com/automagik-dev/genie/… | automagik-dev/genie ✓|
| @automagik/omni | github.com/automagik/omni/… | automagik-dev/omni ✗ |
| @automagik/pgserve | github.com/automagik/pgserve/… | namastexlabs/pgserve✗|
Verified via `git remote -v` in /repos/omni and /repos/pgserve. The
release-publish.yml workflow's `gh attestation verify --owner namastexlabs`
already uses the correct owner — the bug was only in the in-process
verifier.
Impact without this fix:
- `pgserve verify` against any actually-signed pgserve binary fails
because cosign's --certificate-identity-regexp never matches
`namastexlabs/pgserve` against a regex pinned to `automagik/pgserve`.
Same for omni.
- Wave 2 G3 ships a "manifest LOCK 1" verifier that deep-clones
TRUSTED_IDENTITIES at create-app time. Without this fix, LOCK 1
would freeze the broken regex into every per-consumer manifest in
perpetuity. Operators would never reach a working verify state.
Surfaced by: pre-flight audit during ENGINEER-AUDIT-G5 cross-checking;
2/3 hardcoded trust roots had wrong-org references.
No tests pin the literal regex string; cache-token + verify tests use
the `id` field (`automagik-pgserve-release` etc.), which is unchanged.
trust-store tests use generic regexes (`^https://github.com/acme/.*$`).
Validation:
bun test tests/cosign/ tests/cli/trust.test.js tests/cli/verify.test.js → 83/83 pass
bun run lint → clean
bun run deadcode → clean (only pre-existing knip config hints)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe PR reformats property line ordering within two entries of the hardcoded ChangesTrust List Entry Formatting
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Code Review
This pull request updates the GitHub repository paths in the identityRegexp for the omni and pgserve release workflows. A review comment identifies a potential mismatch in the pgserve workflow filename, suggesting that release-publish.yml should be used instead of release.yml to ensure successful OIDC identity verification.
| publisher: '@automagik/pgserve', | ||
| issuer: SIGSTORE_GITHUB_ACTIONS_ISSUER, | ||
| identityRegexp: '^https://github.com/automagik/pgserve/.github/workflows/release.yml@refs/tags/v.*$', | ||
| identityRegexp: '^https://github.com/namastexlabs/pgserve/.github/workflows/release.yml@refs/tags/v.*$', |
There was a problem hiding this comment.
The pull request description explicitly mentions that the release-publish.yml workflow in the namastexlabs/pgserve repository is used for attestations. However, the identityRegexp updated here still references release.yml. If release-publish.yml is indeed the workflow responsible for signing the binary, this regex will fail to match the OIDC identity during verification. Please verify the correct filename and update the regex if necessary.
| identityRegexp: '^https://github.com/namastexlabs/pgserve/.github/workflows/release.yml@refs/tags/v.*$', | |
| identityRegexp: '^https://github.com/namastexlabs/pgserve/.github/workflows/release-publish.yml@refs/tags/v.*$', |
Summary
Two of the three hardcoded
TRUSTED_IDENTITIESregexes insrc/cosign/trust-list.jsreferenced GitHub orgs that don't host the actual release workflows. Without this fix,pgserve verifyagainst any actually-signed pgserve binary fails — and the upcoming wave 2 G3 "manifest LOCK 1" verifier would freeze the broken values into every per-consumer manifest in perpetuity.@automagik/geniegithub.com/automagik-dev/genie/…automagik-dev/genie@automagik/omnigithub.com/automagik/omni/…automagik-dev/omni@automagik/pgservegithub.com/automagik/pgserve/…namastexlabs/pgserveVerified org names via
git remote -vin/repos/omniand/repos/pgserve. Therelease-publish.ymlworkflow'sgh attestation verify --owner namastexlabsalready uses the correct owner — the bug was only in the in-process verifier (used bypgserve verifyand the upcomingpgserve create-appLOCK 1 path).Why now
Surfaced during pre-flight audit of wave 4 G5 (
ENGINEER-AUDIT-G5.md) while warming up on wave 2 G3 deliverables. Held wave 2 G3 dispatch: G3's manifest LOCK 1 verifier deep-clonesTRUSTED_IDENTITIESatpgserve create-apptime, so a wrong-regex live state would lock broken trust roots into every consumer's frozen manifest. Best to land before G3 starts coding.Test plan
bun test tests/cosign/ tests/cli/trust.test.js tests/cli/verify.test.js→ 83 pass / 0 failbun run lint→ cleanbun run deadcode→ clean (only pre-existing knip config hints)grep -rn "automagik/omni\|automagik/pgserve" tests/— onlytests/cli/verify.test.js:238references'@automagik/pgserve'which is the npm package name field, not the regex)pgserve verifyagainst a real signed binary (route to qa for smoke)Out of scope (follow-ups, not blockers)
publisher: '@automagik/pgserve'literal still lives in trust-list.js:52 even though the actual published npm package name ispgserve(no scope) pernpm view pgserve. Worth a separate audit; not changed here per orchestrator's tight-scope instruction.🤖 Generated with Claude Code
Summary by CodeRabbit