feat: add hosted feed envelope verifier#98299
Conversation
|
Codex review: needs maintainer review before merge. Reviewed July 8, 2026, 10:19 PM ET / 02:19 UTC. Summary PR surface: Source +266, Tests +296. Total +562 across 5 files. Reproducibility: not applicable. as a feature PR; the changed behavior is source-reproducible through the verifier harness and focused Vitest described in the PR body and comments. Review metrics: 1 noteworthy metric.
Stored data model Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Land this narrow verifier primitive only after maintainer security-boundary approval and exact-head checks, then keep config, refresh-state, and CLI trust rendering in the stacked follow-up PRs. Do we have a high-confidence way to reproduce the issue? Not applicable as a feature PR; the changed behavior is source-reproducible through the verifier harness and focused Vitest described in the PR body and comments. Is this the best way to solve the issue? Yes; after the prior DSSE and signature-bound fixes, sharing Ed25519 helpers and exposing a lazy verifier is a narrow foundation while keeping refresh/config wiring in follow-up PRs. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 0307deacfac7. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +266, Tests +296. Total +562 across 5 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (15 earlier review cycles; latest 8 shown)
|
|
@clawsweeper re-review Updated at |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
@clawsweeper re-review Proof and implementation have been refreshed since the current stale verdict: head |
|
@clawsweeper re-review Rebased the verifier-primitive PR onto current Carry-forward proof from the rebased head:
Please refresh the durable verdict for this exact head before merge. |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
@clawsweeper re-review Prepared head Fresh exact-head local proof:
Please refresh the durable verdict for this exact head before merge. |
|
🦞🧹 I asked ClawSweeper to review this item again. |
Dependency graph guard clearedThis PR no longer has blocked dependency graph changes. A future dependency graph change requires a fresh
|
This reverts commit 448f05f.
|
@clawsweeper re-review Restored #98299 to the intended verifier-only diff and rebased onto current Notes:
Fresh exact-head local proof:
Please refresh the durable verdict for this exact head. |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
Merged via squash.
|
Related: openclaw/rfcs#25
What Problem This Solves
Starts the hosted feed trust-verification implementation series by adding the signed envelope verifier primitives that later feed refresh and source-profile PRs can consume.
Why This Change Was Made
This adds a small, isolated verifier for OpenClaw-hosted external plugin catalog envelopes. It verifies Ed25519 signatures over DSSE PAE using the decoded serialized payload bytes, accepts PEM or raw base64url public keys, validates the payload type, and only parses the feed after a trusted signature verifies.
This PR intentionally does not wire signed envelopes into marketplace refresh, config, snapshot persistence, CLI output, or install eligibility. Those stay in follow-up PRs from the RFC trust series.
The Ed25519 PEM/raw-key verification helpers are shared with device identity code so the new feed verifier does not fork a second signature implementation.
User Impact
No user-visible behavior changes yet. This is a draft implementation foundation for future signed hosted feed verification.
Real behavior proof
Behavior or issue addressed:
Signed hosted feed envelopes can be verified against an explicit trusted Ed25519 key using DSSE PAE over decoded serialized payload bytes. Equivalent URL-safe and standard base64 encodings of the same payload bytes verify against the same signature input; payload bytes changed after signing are rejected before the feed is trusted; malformed raw signature arrays are capped before filtering or verification.
Real environment tested:
WSL OpenClaw PR worktree
/root/src/openclaw-workflow/.worktrees/pr-98299-fixat PR head297003b252cdc57b7f3f3e53c54113ae28f4001b; source harness usingnode --import tsx -; generated in-memory Ed25519 proof key; no network service or persisted cache involved.Exact steps or command run after this patch:
createOfficialExternalPluginCatalogEnvelopePayload,createOfficialExternalPluginCatalogEnvelopeSigningInput, andverifyOfficialExternalPluginCatalogSignedEnvelopefromsrc/plugins/official-external-plugin-catalog-envelope.ts.clawhub-officialfeed payload as URL-safe base64, sign DSSE PAE over the decoded payload bytes, and verify the URL-safe envelope with a trusted PEM key.invalid-envelopebefore malformed entries are filtered.Evidence after fix:
{ "signingInputUtf8Prefix": "DSSEv1 49 openclaw.official-external-plugin-catalog-feed.v1 259 ", "decodedPayloadBytes": 259, "acceptedUrlSafe": true, "acceptedStandard": true, "acceptedStandardSignedBy": "clawhub-root-2026", "tamperedRejected": true, "excessiveRawRejected": true }Observed result after fix:
The verifier accepted the signed feed envelope with both URL-safe and standard base64 payload encodings of the same decoded bytes, rejected the tampered payload with
invalid-signature, and rejected the malformed raw signature overflow envelope withinvalid-envelope.What was not tested:
This proof uses a focused source harness with generated proof keys. It does not test live ClawHub hosted envelope publication, marketplace refresh wiring, config trust-root selection, snapshot trust-state persistence, CLI output, or install eligibility because those are intentionally deferred to later PRs in the trust series.
Validation