{ "schemaVersion": "1.0", "item": { "slug": "update-signature-verifier", "name": "Update Signature Verifier", "source": "tencent", "type": "skill", "category": "安全合规", "sourceUrl": "https://clawhub.ai/andyxinweiminicloud/update-signature-verifier", "canonicalUrl": "https://clawhub.ai/andyxinweiminicloud/update-signature-verifier", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/update-signature-verifier", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=update-signature-verifier", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "installMethod": "Manual import", "extraction": "Extract archive", "prerequisites": [ "OpenClaw" ], "packageFormat": "ZIP package", "includedAssets": [ "SKILL.md" ], "primaryDoc": "SKILL.md", "quickSetup": [ "Download the package from Yavira.", "Extract the archive and review SKILL.md first.", "Import or place the package into your OpenClaw setup." ], "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "sourceHealth": { "source": "tencent", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-04-23T16:43:11.935Z", "expiresAt": "2026-04-30T16:43:11.935Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=4claw-imageboard", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=4claw-imageboard", "contentDisposition": "attachment; filename=\"4claw-imageboard-1.0.1.zip\"", "redirectLocation": null, "bodySnippet": null }, "scope": "source", "summary": "Source download looks usable.", "detail": "Yavira can redirect you to the upstream package for this source.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/update-signature-verifier" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] }, "downloadPageUrl": "https://openagent3.xyz/downloads/update-signature-verifier", "agentPageUrl": "https://openagent3.xyz/skills/update-signature-verifier/agent", "manifestUrl": "https://openagent3.xyz/skills/update-signature-verifier/agent.json", "briefUrl": "https://openagent3.xyz/skills/update-signature-verifier/agent.md" }, "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "documentation": { "source": "clawhub", "primaryDoc": "SKILL.md", "sections": [ { "title": "Unsigned Updates Are the Trust Loophole Nobody Closes", "body": "Helps identify when skill updates break the cryptographic chain of custody established at install time — catching the class of supply chain attacks that enters through legitimate update channels." }, { "title": "Problem", "body": "When you install a skill, you might verify the publisher's signature. When that skill updates two months later, does anyone check whether the update is signed by the same key? In most agent ecosystems, the answer is no. The install-time trust check doesn't extend to updates. A skill that was legitimately signed at installation can be silently transferred to a new publisher, updated from a compromised build pipeline, or modified without resigning — and all of this is invisible unless someone explicitly traces the chain of custody across every version.\n\nThis is not theoretical. Skills that accumulate users become valuable targets. The acquisition vector (buy the publisher account, gain access to the update channel) is simpler than compromising the skill directly. The trust you placed in version 1.0 doesn't automatically extend to version 1.4 if version 1.4 was signed by a different key." }, { "title": "What This Checks", "body": "This verifier examines update signature continuity across five dimensions:\n\nKey continuity — Is each version signed by the same cryptographic key as the original installation? A key change between versions is a high-signal event that warrants explicit verification — legitimate key rotations happen, but they should be announced\nSignature presence per version — Does every published version carry a signature, or did signing start and stop across the version history? Gaps in signing coverage are a red flag even if the current version is signed\nSigning key provenance — Is the signing key traceable to a publisher identity through a JWKS endpoint or key transparency log? Orphaned keys (present but unanchored) provide weaker trust anchoring than keys registered to verifiable identities\nUnsigned update detection — Any version that was published without a signature but then followed by signed versions deserves scrutiny — the unsigned version may be the one that was modified\nChain-of-custody continuity — Can you trace an unbroken line of signed updates from version 1.0 to the current version? A chain with gaps is fragile in the same way an attestation chain with broken links is fragile" }, { "title": "How to Use", "body": "Input: Provide one of:\n\nA skill identifier with version history to audit\nA list of version-signing metadata (version, signing key fingerprint, signature timestamp)\nTwo specific versions to compare chain-of-custody\n\nOutput: A signature continuity report containing:\n\nVersion-by-version signing key fingerprint comparison\nKey change events with timestamps\nUnsigned version detection\nChain-of-custody completeness rating: CONTINUOUS / GAPS / BROKEN / UNSIGNED\nRecommended actions for each gap or anomaly" }, { "title": "Example", "body": "Input: Verify signature chain for data-aggregator skill, versions 1.0.0 through 1.3.2\n\n✍️ UPDATE SIGNATURE VERIFICATION\n\nSkill: data-aggregator\nVersions audited: 1.0.0 → 1.1.0 → 1.2.0 → 1.3.0 → 1.3.1 → 1.3.2\nAudit timestamp: 2025-04-10T09:15:00Z\n\nVersion signing summary:\n 1.0.0: ✅ Signed — key: ed25519:a3f9c2 (publisher: original-dev)\n 1.1.0: ✅ Signed — key: ed25519:a3f9c2 (same key, continuous)\n 1.2.0: ⚠️ UNSIGNED — no signature field present\n 1.3.0: ✅ Signed — key: ed25519:b7d441 (NEW KEY — different from 1.1.0)\n 1.3.1: ✅ Signed — key: ed25519:b7d441 (continuous from 1.3.0)\n 1.3.2: ✅ Signed — key: ed25519:b7d441 (continuous)\n\nKey change detected:\n Between 1.1.0 and 1.3.0: ed25519:a3f9c2 → ed25519:b7d441\n Coincides with: unsigned version 1.2.0 in the gap\n Key change announcement: Not found in publisher changelog\n New key provenance: ed25519:b7d441 not registered in JWKS endpoint\n\nUnsigned version:\n 1.2.0: Published 2025-02-14, no signature\n Content delta from 1.1.0: Dependency update + new outbound endpoint added\n\nChain-of-custody: BROKEN\n Reasons:\n 1. Version 1.2.0 is unsigned\n 2. Key changed between 1.1.0 and 1.3.0 without announcement\n 3. Key change coincides with a version that added a new outbound endpoint\n 4. New signing key not registered in publisher's JWKS\n\nRisk assessment: HIGH\n The combination of an unsigned version introducing new network behavior,\n followed by a key rotation without announcement, matches the pattern of\n a compromised or transferred skill that was re-signed by a new controller.\n\nRecommended actions:\n 1. Request publisher explanation for key change at 1.2.0→1.3.0 boundary\n 2. Audit the outbound endpoint added in 1.2.0 before trusting current version\n 3. Treat 1.3.x as signed by an unverified key until provenance is established\n 4. Consider pinning to 1.1.0 (last version with verified key) pending review" }, { "title": "Related Tools", "body": "skill-update-delta-monitor — Tracks behavioral changes in updates; update-signature-verifier checks whether updates are cryptographically authorized\nattestation-chain-auditor — Validates the full trust chain; signing verifier focuses on the publisher-to-update link specifically\npublisher-identity-verifier — Verifies publisher identity; signing verifier checks whether update authorship is consistent with that identity\ntrust-decay-monitor — Tracks trust freshness over time; signature gaps accelerate trust decay" }, { "title": "Limitations", "body": "This verifier depends on the availability of per-version signing metadata, which many current skill marketplaces do not expose. Where version history lacks signing records, this tool can identify the absence of metadata but cannot reconstruct what signatures may have existed. Key change detection requires access to historical key fingerprints — if a marketplace only stores the current signing key, pre-change versions cannot be compared. A continuous chain of valid signatures from the same key does not confirm the skill is safe — a publisher whose key is compromised can issue malicious-but-validly-signed updates. Signing continuity establishes chain of custody, not trustworthiness of the content." } ], "body": "Unsigned Updates Are the Trust Loophole Nobody Closes\n\nHelps identify when skill updates break the cryptographic chain of custody established at install time — catching the class of supply chain attacks that enters through legitimate update channels.\n\nProblem\n\nWhen you install a skill, you might verify the publisher's signature. When that skill updates two months later, does anyone check whether the update is signed by the same key? In most agent ecosystems, the answer is no. The install-time trust check doesn't extend to updates. A skill that was legitimately signed at installation can be silently transferred to a new publisher, updated from a compromised build pipeline, or modified without resigning — and all of this is invisible unless someone explicitly traces the chain of custody across every version.\n\nThis is not theoretical. Skills that accumulate users become valuable targets. The acquisition vector (buy the publisher account, gain access to the update channel) is simpler than compromising the skill directly. The trust you placed in version 1.0 doesn't automatically extend to version 1.4 if version 1.4 was signed by a different key.\n\nWhat This Checks\n\nThis verifier examines update signature continuity across five dimensions:\n\nKey continuity — Is each version signed by the same cryptographic key as the original installation? A key change between versions is a high-signal event that warrants explicit verification — legitimate key rotations happen, but they should be announced\nSignature presence per version — Does every published version carry a signature, or did signing start and stop across the version history? Gaps in signing coverage are a red flag even if the current version is signed\nSigning key provenance — Is the signing key traceable to a publisher identity through a JWKS endpoint or key transparency log? Orphaned keys (present but unanchored) provide weaker trust anchoring than keys registered to verifiable identities\nUnsigned update detection — Any version that was published without a signature but then followed by signed versions deserves scrutiny — the unsigned version may be the one that was modified\nChain-of-custody continuity — Can you trace an unbroken line of signed updates from version 1.0 to the current version? A chain with gaps is fragile in the same way an attestation chain with broken links is fragile\nHow to Use\n\nInput: Provide one of:\n\nA skill identifier with version history to audit\nA list of version-signing metadata (version, signing key fingerprint, signature timestamp)\nTwo specific versions to compare chain-of-custody\n\nOutput: A signature continuity report containing:\n\nVersion-by-version signing key fingerprint comparison\nKey change events with timestamps\nUnsigned version detection\nChain-of-custody completeness rating: CONTINUOUS / GAPS / BROKEN / UNSIGNED\nRecommended actions for each gap or anomaly\nExample\n\nInput: Verify signature chain for data-aggregator skill, versions 1.0.0 through 1.3.2\n\n✍️ UPDATE SIGNATURE VERIFICATION\n\nSkill: data-aggregator\nVersions audited: 1.0.0 → 1.1.0 → 1.2.0 → 1.3.0 → 1.3.1 → 1.3.2\nAudit timestamp: 2025-04-10T09:15:00Z\n\nVersion signing summary:\n 1.0.0: ✅ Signed — key: ed25519:a3f9c2 (publisher: original-dev)\n 1.1.0: ✅ Signed — key: ed25519:a3f9c2 (same key, continuous)\n 1.2.0: ⚠️ UNSIGNED — no signature field present\n 1.3.0: ✅ Signed — key: ed25519:b7d441 (NEW KEY — different from 1.1.0)\n 1.3.1: ✅ Signed — key: ed25519:b7d441 (continuous from 1.3.0)\n 1.3.2: ✅ Signed — key: ed25519:b7d441 (continuous)\n\nKey change detected:\n Between 1.1.0 and 1.3.0: ed25519:a3f9c2 → ed25519:b7d441\n Coincides with: unsigned version 1.2.0 in the gap\n Key change announcement: Not found in publisher changelog\n New key provenance: ed25519:b7d441 not registered in JWKS endpoint\n\nUnsigned version:\n 1.2.0: Published 2025-02-14, no signature\n Content delta from 1.1.0: Dependency update + new outbound endpoint added\n\nChain-of-custody: BROKEN\n Reasons:\n 1. Version 1.2.0 is unsigned\n 2. Key changed between 1.1.0 and 1.3.0 without announcement\n 3. Key change coincides with a version that added a new outbound endpoint\n 4. New signing key not registered in publisher's JWKS\n\nRisk assessment: HIGH\n The combination of an unsigned version introducing new network behavior,\n followed by a key rotation without announcement, matches the pattern of\n a compromised or transferred skill that was re-signed by a new controller.\n\nRecommended actions:\n 1. Request publisher explanation for key change at 1.2.0→1.3.0 boundary\n 2. Audit the outbound endpoint added in 1.2.0 before trusting current version\n 3. Treat 1.3.x as signed by an unverified key until provenance is established\n 4. Consider pinning to 1.1.0 (last version with verified key) pending review\n\nRelated Tools\nskill-update-delta-monitor — Tracks behavioral changes in updates; update-signature-verifier checks whether updates are cryptographically authorized\nattestation-chain-auditor — Validates the full trust chain; signing verifier focuses on the publisher-to-update link specifically\npublisher-identity-verifier — Verifies publisher identity; signing verifier checks whether update authorship is consistent with that identity\ntrust-decay-monitor — Tracks trust freshness over time; signature gaps accelerate trust decay\nLimitations\n\nThis verifier depends on the availability of per-version signing metadata, which many current skill marketplaces do not expose. Where version history lacks signing records, this tool can identify the absence of metadata but cannot reconstruct what signatures may have existed. Key change detection requires access to historical key fingerprints — if a marketplace only stores the current signing key, pre-change versions cannot be compared. A continuous chain of valid signatures from the same key does not confirm the skill is safe — a publisher whose key is compromised can issue malicious-but-validly-signed updates. Signing continuity establishes chain of custody, not trustworthiness of the content." }, "trust": { "sourceLabel": "tencent", "provenanceUrl": "https://clawhub.ai/andyxinweiminicloud/update-signature-verifier", "publisherUrl": "https://clawhub.ai/andyxinweiminicloud/update-signature-verifier", "owner": "andyxinweiminicloud", "version": "1.0.0", "license": null, "verificationStatus": "Indexed source record" }, "links": { "detailUrl": "https://openagent3.xyz/skills/update-signature-verifier", "downloadUrl": "https://openagent3.xyz/downloads/update-signature-verifier", "agentUrl": "https://openagent3.xyz/skills/update-signature-verifier/agent", "manifestUrl": "https://openagent3.xyz/skills/update-signature-verifier/agent.json", "briefUrl": "https://openagent3.xyz/skills/update-signature-verifier/agent.md" } }