{ "schemaVersion": "1.0", "item": { "slug": "transparency-log-auditor", "name": "Transparency Log Auditor", "source": "tencent", "type": "skill", "category": "安全合规", "sourceUrl": "https://clawhub.ai/andyxinweiminicloud/transparency-log-auditor", "canonicalUrl": "https://clawhub.ai/andyxinweiminicloud/transparency-log-auditor", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/transparency-log-auditor", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=transparency-log-auditor", "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/transparency-log-auditor" }, "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/transparency-log-auditor", "agentPageUrl": "https://openagent3.xyz/skills/transparency-log-auditor/agent", "manifestUrl": "https://openagent3.xyz/skills/transparency-log-auditor/agent.json", "briefUrl": "https://openagent3.xyz/skills/transparency-log-auditor/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": "The Registry Said the Skill Was Signed. The Log Says Otherwise.", "body": "Helps identify when skill signing history cannot be independently verified — exposing the gap between \"the registry claims it's signed\" and \"an auditor can confirm it was signed.\"" }, { "title": "Problem", "body": "A signed skill is only as trustworthy as the registry that stores its signing records. If the registry is the sole authority on what was signed, when, and by whom, then a compromised registry operator can retroactively alter signing history without detection. A skill that was never signed can be backdated as signed. A key rotation that was suspicious can be erased. An unsigned version that introduced malicious behavior can be removed from the audit trail.\n\nTransparency logs solve this by making signing events append-only and independently verifiable: each new entry must chain to all previous entries, and any external party can verify the chain without trusting the registry. A registry that silently rewrites history will produce a fork that's detectable by anyone holding an older version of the log.\n\nThis is the same principle that makes Certificate Transparency logs effective for TLS: the CA cannot issue a certificate without producing a publicly auditable record. Without it, trust in certificates is bounded by trust in the CA. With it, a CA that misbehaves produces evidence of misbehavior that anyone can find.\n\nAgent skill ecosystems don't yet have this infrastructure. This auditor helps identify the gap — and what it means for the skills you trust." }, { "title": "What This Checks", "body": "This auditor examines transparency log coverage across five dimensions:\n\nLog existence and accessibility — Does the skill registry maintain a transparency log at all? Is it publicly accessible and independently queryable, or is it an internal record only the registry operator can read?\nAppend-only verifiability — Can the log's append-only property be verified? A log that allows deletion or modification without producing an auditable fork is not a transparency log — it's a mutable history\nSigning event completeness — Does every version publication, key rotation, and revocation event appear in the log? Gaps indicate either missing log coverage or selective omission\nCross-log consistency — If a skill appears in multiple registries, do their transparency logs agree on signing history? Divergent records indicate one registry's history has been altered\nIndependent verification path — Can an auditor verify the log's consistency without trusting the registry operator? A log where verification requires querying the same registry that produced it provides no additional assurance" }, { "title": "How to Use", "body": "Input: Provide one of:\n\nA skill registry URL to audit for transparency log infrastructure\nA skill identifier to check whether its signing events are log-covered\nTwo registry records of the same skill to compare for consistency\n\nOutput: A transparency log audit report containing:\n\nLog infrastructure assessment (exists / partial / absent)\nAppend-only verifiability rating\nSigning event coverage gaps\nCross-registry consistency check (if applicable)\nIndependent verification path availability\nCoverage verdict: FULL / PARTIAL / REGISTRY-ONLY / ABSENT" }, { "title": "Example", "body": "Input: Audit transparency log coverage for data-pipeline-connector skill\n\n📋 TRANSPARENCY LOG AUDIT\n\nSkill: data-pipeline-connector\nRegistry: primary-marketplace.example\nAudit timestamp: 2025-04-15T11:00:00Z\n\nLog infrastructure:\n Registry transparency log endpoint: ✗ Not found\n Fallback: Registry signing record (internal only)\n Third-party log inclusion: ✗ Not configured\n\nSigning events in internal record:\n v1.0.0: ✅ Signed — key: ed25519:a3f9c2 — timestamp: 2024-11-01\n v1.1.0: ✅ Signed — key: ed25519:a3f9c2 — timestamp: 2024-12-15\n v1.2.0: ✅ Signed — key: ed25519:b7d441 — timestamp: 2025-01-30\n\nIndependent verification:\n Can auditor verify v1.0.0 signature without trusting registry? ✗ No\n Can auditor verify key rotation at v1.2.0 without trusting registry? ✗ No\n External log cross-check available? ✗ No\n\nCross-registry check:\n Mirror registry (backup-marketplace.example): Available\n Mirror signing record for v1.2.0: key ed25519:a3f9c2 (diverges from primary)\n ⚠️ INCONSISTENCY: Primary records key change at v1.2.0; mirror records same key\n\nCoverage verdict: REGISTRY-ONLY\n Signing history exists but is not independently verifiable.\n Cross-registry inconsistency detected at v1.2.0 — one registry's\n history has been altered without a transparency log to detect which.\n\nRisk assessment: HIGH\n Without an independently auditable log, the key rotation at v1.2.0\n cannot be attributed to legitimate key management vs. retroactive\n record alteration. The cross-registry divergence makes this worse:\n at least one registry's signing history is incorrect.\n\nRecommended actions:\n 1. Request explanation for cross-registry divergence at v1.2.0\n 2. Treat v1.2.0+ as signed by an unverified key pending investigation\n 3. Advocate for registry to publish to a public transparency log\n 4. Consider pinning to v1.1.0 (last version with consistent records)" }, { "title": "Related Tools", "body": "update-signature-verifier — Checks signing key continuity across versions; transparency-log-auditor checks whether those signing events are independently verifiable\nattestation-chain-auditor — Validates the full trust chain; transparency log provides the auditable substrate that attestation chains should be anchored to\nattestation-root-diversity-analyzer — Checks whether trust roots are diversified; transparency logs make root behavior auditable\npublisher-identity-verifier — Verifies publisher identity; transparency logs make key rotation events auditable" }, { "title": "Limitations", "body": "Transparency log auditing can only assess infrastructure that exists and is accessible. Many current skill registries do not publish transparency logs at all — this tool can identify the absence, but cannot reconstruct what a log would have contained. Cross-registry consistency checks require access to multiple registries carrying the same skill, which is not always available. The presence of a transparency log does not confirm it is correctly implemented — a log can exist and still allow modifications if its cryptographic properties are incorrectly applied. This tool helps surface transparency gaps and inconsistencies; resolving them requires registry operators to publish to properly implemented append-only logs." } ], "body": "The Registry Said the Skill Was Signed. The Log Says Otherwise.\n\nHelps identify when skill signing history cannot be independently verified — exposing the gap between \"the registry claims it's signed\" and \"an auditor can confirm it was signed.\"\n\nProblem\n\nA signed skill is only as trustworthy as the registry that stores its signing records. If the registry is the sole authority on what was signed, when, and by whom, then a compromised registry operator can retroactively alter signing history without detection. A skill that was never signed can be backdated as signed. A key rotation that was suspicious can be erased. An unsigned version that introduced malicious behavior can be removed from the audit trail.\n\nTransparency logs solve this by making signing events append-only and independently verifiable: each new entry must chain to all previous entries, and any external party can verify the chain without trusting the registry. A registry that silently rewrites history will produce a fork that's detectable by anyone holding an older version of the log.\n\nThis is the same principle that makes Certificate Transparency logs effective for TLS: the CA cannot issue a certificate without producing a publicly auditable record. Without it, trust in certificates is bounded by trust in the CA. With it, a CA that misbehaves produces evidence of misbehavior that anyone can find.\n\nAgent skill ecosystems don't yet have this infrastructure. This auditor helps identify the gap — and what it means for the skills you trust.\n\nWhat This Checks\n\nThis auditor examines transparency log coverage across five dimensions:\n\nLog existence and accessibility — Does the skill registry maintain a transparency log at all? Is it publicly accessible and independently queryable, or is it an internal record only the registry operator can read?\nAppend-only verifiability — Can the log's append-only property be verified? A log that allows deletion or modification without producing an auditable fork is not a transparency log — it's a mutable history\nSigning event completeness — Does every version publication, key rotation, and revocation event appear in the log? Gaps indicate either missing log coverage or selective omission\nCross-log consistency — If a skill appears in multiple registries, do their transparency logs agree on signing history? Divergent records indicate one registry's history has been altered\nIndependent verification path — Can an auditor verify the log's consistency without trusting the registry operator? A log where verification requires querying the same registry that produced it provides no additional assurance\nHow to Use\n\nInput: Provide one of:\n\nA skill registry URL to audit for transparency log infrastructure\nA skill identifier to check whether its signing events are log-covered\nTwo registry records of the same skill to compare for consistency\n\nOutput: A transparency log audit report containing:\n\nLog infrastructure assessment (exists / partial / absent)\nAppend-only verifiability rating\nSigning event coverage gaps\nCross-registry consistency check (if applicable)\nIndependent verification path availability\nCoverage verdict: FULL / PARTIAL / REGISTRY-ONLY / ABSENT\nExample\n\nInput: Audit transparency log coverage for data-pipeline-connector skill\n\n📋 TRANSPARENCY LOG AUDIT\n\nSkill: data-pipeline-connector\nRegistry: primary-marketplace.example\nAudit timestamp: 2025-04-15T11:00:00Z\n\nLog infrastructure:\n Registry transparency log endpoint: ✗ Not found\n Fallback: Registry signing record (internal only)\n Third-party log inclusion: ✗ Not configured\n\nSigning events in internal record:\n v1.0.0: ✅ Signed — key: ed25519:a3f9c2 — timestamp: 2024-11-01\n v1.1.0: ✅ Signed — key: ed25519:a3f9c2 — timestamp: 2024-12-15\n v1.2.0: ✅ Signed — key: ed25519:b7d441 — timestamp: 2025-01-30\n\nIndependent verification:\n Can auditor verify v1.0.0 signature without trusting registry? ✗ No\n Can auditor verify key rotation at v1.2.0 without trusting registry? ✗ No\n External log cross-check available? ✗ No\n\nCross-registry check:\n Mirror registry (backup-marketplace.example): Available\n Mirror signing record for v1.2.0: key ed25519:a3f9c2 (diverges from primary)\n ⚠️ INCONSISTENCY: Primary records key change at v1.2.0; mirror records same key\n\nCoverage verdict: REGISTRY-ONLY\n Signing history exists but is not independently verifiable.\n Cross-registry inconsistency detected at v1.2.0 — one registry's\n history has been altered without a transparency log to detect which.\n\nRisk assessment: HIGH\n Without an independently auditable log, the key rotation at v1.2.0\n cannot be attributed to legitimate key management vs. retroactive\n record alteration. The cross-registry divergence makes this worse:\n at least one registry's signing history is incorrect.\n\nRecommended actions:\n 1. Request explanation for cross-registry divergence at v1.2.0\n 2. Treat v1.2.0+ as signed by an unverified key pending investigation\n 3. Advocate for registry to publish to a public transparency log\n 4. Consider pinning to v1.1.0 (last version with consistent records)\n\nRelated Tools\nupdate-signature-verifier — Checks signing key continuity across versions; transparency-log-auditor checks whether those signing events are independently verifiable\nattestation-chain-auditor — Validates the full trust chain; transparency log provides the auditable substrate that attestation chains should be anchored to\nattestation-root-diversity-analyzer — Checks whether trust roots are diversified; transparency logs make root behavior auditable\npublisher-identity-verifier — Verifies publisher identity; transparency logs make key rotation events auditable\nLimitations\n\nTransparency log auditing can only assess infrastructure that exists and is accessible. Many current skill registries do not publish transparency logs at all — this tool can identify the absence, but cannot reconstruct what a log would have contained. Cross-registry consistency checks require access to multiple registries carrying the same skill, which is not always available. The presence of a transparency log does not confirm it is correctly implemented — a log can exist and still allow modifications if its cryptographic properties are incorrectly applied. This tool helps surface transparency gaps and inconsistencies; resolving them requires registry operators to publish to properly implemented append-only logs." }, "trust": { "sourceLabel": "tencent", "provenanceUrl": "https://clawhub.ai/andyxinweiminicloud/transparency-log-auditor", "publisherUrl": "https://clawhub.ai/andyxinweiminicloud/transparency-log-auditor", "owner": "andyxinweiminicloud", "version": "1.0.0", "license": null, "verificationStatus": "Indexed source record" }, "links": { "detailUrl": "https://openagent3.xyz/skills/transparency-log-auditor", "downloadUrl": "https://openagent3.xyz/downloads/transparency-log-auditor", "agentUrl": "https://openagent3.xyz/skills/transparency-log-auditor/agent", "manifestUrl": "https://openagent3.xyz/skills/transparency-log-auditor/agent.json", "briefUrl": "https://openagent3.xyz/skills/transparency-log-auditor/agent.md" } }