Back to skill
Skillv1.0.0

ClawScan security

fadada-esign · ClawHub's context-aware review of the artifact, metadata, and declared behavior.

Scanner verdict

SuspiciousApr 14, 2026, 10:08 AM
Verdict
suspicious
Confidence
medium
Model
gpt-5-mini
Summary
The package generally implements a FaDaDa e-sign SDK and legitimately needs FaDaDa credentials, but there are multiple inconsistencies between the manifest, documentation, and code (including conflicting signing algorithms and undocumented credential requirements), so proceed only after manual verification.
Guidance
This package looks like a FaDaDa (法大大) e-sign SDK and reasonably needs FaDaDa credentials, but there are inconsistencies that warrant caution. Before installing or giving it any secrets: 1) Verify provenance — find the upstream/source repository (setup.py points at a GitHub URL) and compare files to an official FaDaDa SDK; 2) Prefer testing in a sandbox account and use sandbox mode if available; 3) Do not store your production app_secret in shared or world-readable config files — prefer environment variables and check that config files created by the tool do not contain the secret; 4) Inspect the code yourself (or have a developer do so) to confirm which signing algorithm and endpoints are used (client.py implements HMAC-SHA256 while some docs show MD5 — confirm which your FaDaDa account expects); 5) Run the CLI in an isolated environment/container and with only test credentials to ensure behavior matches expectations; 6) If you cannot confirm the source or resolve the doc/code conflicts, avoid using production credentials with this package. If you want, provide the upstream repository link (or the publisher identity) and I can re-check differences and point to exact files that mismatch.

Review Dimensions

Purpose & Capability
concernName, description, and most files consistently implement an e-signature SDK (upload, create sign task, query, download). However the registry metadata lists no required environment variables or primary credential while SKILL.md and code clearly expect FADADA_APP_ID / FADADA_APP_SECRET / FADADA_OPEN_CORP_ID — a manifest/documentation mismatch that is incoherent and worth flagging.
Instruction Scope
concernRuntime instructions and code perform expected actions (read config from ~/.fadada or local .fadada.json, read files to upload, call external API endpoints). But there are conflicting/inconsistent instructions across files: one SKILL.md and some reference docs describe an MD5-based signature (AppId+Timestamp+MsgId+AppSecret) while client.py implements a two-step HMAC-SHA256 scheme; various example scripts expect different response codes/JSON formats. Those inconsistencies could lead to misconfiguration or misuse and indicate the package is a mix of multiple versions.
Install Mechanism
okNo install spec in the skill metadata (instruction-only from the platform perspective). The package includes a standard setup.py and pure-Python code that depends on requests; no remote downloads, obfuscated binaries, or unusual install URLs were observed.
Credentials
concernThe secrets the code requests (app_id, app_secret, open_corp_id) are appropriate for an e-sign SDK. However the registry metadata did not declare these required env vars, and multiple files/examples show different places to store secrets (env, config file, or code). The code reads configuration files in the current directory and the user's home directory (~/.fadada), which is expected but means existing local configs could be picked up unexpectedly. Overall credential use is proportionate to the claimed purpose but the metadata omission and inconsistent handling are concerning.
Persistence & Privilege
okSkill is not always-included and is user-invocable. It does write a per-user config file (~/.fadada/config.json) via its interactive setup, but the save() implementation intentionally omits app_secret when writing; the skill does not request system-wide privileges or modify other skills. Autonomous invocation is allowed but that is the platform default.