Moltbook Signed Posts
AdvisoryAudited by Static analysis on Apr 30, 2026.
Overview
No suspicious patterns detected.
Findings (0)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If the private key is exposed, someone else could make posts that appear to be signed by the same agent identity.
The signer uses a persistent private key as the agent's posting identity. This is purpose-aligned, but the key is sensitive because anyone with it can create matching signatures.
PRIVATE_KEY="${MOLTBOOK_SIGNING_KEY:-$HOME/.config/moltbook/signing_key.pem}" ... openssl pkeyutl -sign -inkey "$PRIVATE_KEY"Keep the private key secret, prefer the bundled keygen script or chmod 600 permissions, avoid shared/synced folders for the key, and rotate the key if it is exposed.
Running the skill executes local crypto commands and writes key files, but the artifacts do not show unrelated command execution.
The skill relies on local shell scripts invoking OpenSSL to generate and use keys. This is expected for a local cryptographic signing helper.
openssl genpkey -algorithm Ed25519 -out "$PRIVATE_KEY" ... chmod 600 "$PRIVATE_KEY"
Run only the reviewed bundled scripts from a trusted directory and ensure openssl/base64 come from the system or another trusted source.
The skill may fail or behave differently if openssl/base64 are absent or nonstandard on the user's system.
The package declares required local binaries, while the registry section lists no required binaries and there is no install spec. This is an under-declared dependency issue, not hidden behavior.
"agentskill": { "description": "Sign Moltbook posts with Ed25519 cryptographic signatures for verifiable identity.", "requires": { "bins": ["openssl", "base64"] } }Declare these binary requirements consistently in registry metadata and verify the installed tools before relying on signatures.
An old copied signed post may still verify successfully, so users could falsely assume the timestamp alone prevents reuse.
The timestamp is included in the signed payload, but the provided verification workflow does not document a freshness, nonce, or uniqueness check. The wording overstates replay protection.
- **ts**: Unix timestamp when signed (prevents replay)
Treat the signature as proof that a key signed specific content at a time; add explicit freshness or nonce rules if replay resistance is required.