Security & provenance

Supply chain

The 2025 npm worm era set the bar; Mandare's posture is the post-worm norm done fully:

• pnpm 10 with install scripts OFF globally. The single, documented exception is the embedded-Postgres test binaries (dev-only, exact- pinned, allowlisted in pnpm-workspace.yaml).
• Dependency cooldown: minimumReleaseAge refuses versions younger than 3 days — a worm's blast radius window.
• Frozen lockfile everywhere (CI and the installer both use --frozen-lockfile).
• Few dependencies on purpose. The security-critical primitives are hand-rolled with adversarial test suites rather than imported with their dependency trees. RFC 6962 Merkle proofs and did:key + base58 are pinned to official test vectors; Stripe webhook signatures, the OpenTimestamps client, and canonical JSON are tested against their published wire schemes with round-trip and adversarial suites (no official known-answer vectors are published for those). The Python client is stdlib-only.

Releases (from launch)

• npm packages publish via Trusted Publishing (OIDC) with provenance — no long-lived tokens exist to steal; 2FA required; token publishing disallowed in package settings.
• Docker images: cosign keyless signatures + build provenance attestations, verifiable with gh attestation verify.
• The OpenClaw skill ships a clawhub.skill.verify.v1 envelope — sha256 of every file, Ed25519-signed on tagged releases — with a bundled verifier script (scripts/verify-openclaw-skill.mjs --expect-key <hex>, the key pinned from the release signing key below and the GitHub release's RELEASE-KEY.hex). ClawHub has no publisher signing chain yet; we ship one anyway.
• REPRODUCING.md documents the honest reproducibility bar: pinned lockfile, provenance, independently rebuildable from a tagged commit — and explicitly does not claim bit-for-bit builds.

Release signing key

Tagged releases sign the OpenClaw skill package with this Ed25519 key. Pin it from here, not from the download you are checking:

19895f32484628f53c378eb94899a7a08492b13846bd28efba4e5691ca66e7a8

That is the raw 32-byte public key as 64 lowercase hex characters. Every GitHub release attaches the same value as RELEASE-KEY.hex (listed in the release's SHA256SUMS). If the two ever differ, trust neither and report it (see below).

To verify a downloaded skill package, from a checkout of the repository:

node scripts/verify-openclaw-skill.mjs <skill-directory> \
  --expect-key 19895f32484628f53c378eb94899a7a08492b13846bd28efba4e5691ca66e7a8

Exit 0 and signature VALID and matches --expect-key means every file hash matches and the envelope is signed by this key. An unsigned package, a package signed by any other key, or a run without --expect-key fails on purpose: a valid signature under an unknown key proves nothing.

Rotation. The key changes only if it is compromised or retired. A rotation means a new key, the new hex published on this page and in the next GitHub release, the skill re-signed under it, and a security advisory that names the old key and the date it stopped being valid. A mismatch against your pinned key is therefore always a signal: check this page and the advisories before you accept a new key.

Verify, don't trust

Everything a relying party needs to check Mandare's claims is Apache-2.0 and embeddable, so you can verify without running our stack: the chain verifier, the passport verification, the witness protocol (incl. certificate verification), and the spec's canonical forms. mandare verify and mandare certify verify are thin CLIs over those libraries.

Reporting a vulnerability

Use GitHub Private Vulnerability Reporting on the repository (see SECURITY.md). If you cannot use it, email info@mandarelabs.com with "security" in the subject. Safe harbor for good-faith research; coordinated disclosure within 90 days. Please do not open public issues for security reports.