Back to skill
Skillv0.1.0
ClawScan security
Dingtalk Contact · ClawHub's context-aware review of the artifact, metadata, and declared behavior.
Scanner verdict
ReviewMar 13, 2026, 8:45 AM
- Verdict
- Review
- Confidence
- high
- Model
- gpt-5-mini
- Summary
- The skill legitimately implements DingTalk contact queries, but its metadata omits the credentials it actually requires and the bundled helper will persist secrets to disk and execute shell scripts—this mismatch and persistence are concerning and worth explicit attention.
- Guidance
- This skill does what it says (DingTalk contact lookups) but has some operational and metadata mismatches you should consider before installing: - The package metadata declares no required credentials, but the skill requires DINGTALK_APP_KEY and DINGTALK_APP_SECRET (and may ask for DINGTALK_MY_USER_ID). Expect the skill to prompt you for these and to persist them. - The helper (scripts/dt_helper.sh) stores AppKey/AppSecret and cached tokens in a plaintext file by default at ~/.dingtalk-skills/config. If you install, review and protect that file (filesystem permissions) or override DINGTALK_CONFIG to a secure location. - The skill writes multi-line task scripts to /tmp and executes them (bash /tmp/<task>.sh). That is how it runs the curl calls, but it means the agent will be creating and executing shell scripts—avoid giving it elevated privileges and consider running in an isolated account or environment. - Source/homepage is unknown; if you rely on this in production, request provenance or a signed source. Consider creating an application with the minimal DingTalk scopes and rotate/revoke AppSecret if you stop using the skill. If you want to proceed: (1) verify the script content yourself, (2) provide least-privilege credentials (read-only contact scope), (3) place the config file in a secure location and set restrictive permissions, and (4) consider running the skill in a sandboxed agent session until you are comfortable.
Review Dimensions
- Purpose & Capability
- concernThe skill's name/description match the included scripts and API references (search users/departments, get user details, unionId/userId conversion). However, the registry metadata declares no required environment variables or primary credential, while SKILL.md and scripts clearly require and manage DINGTALK_APP_KEY and DINGTALK_APP_SECRET (and optionally DINGTALK_MY_USER_ID). That omission is an incoherence: a contact-directory skill would reasonably need app credentials, but the metadata should have declared them.
- Instruction Scope
- concernSKILL.md instructs the agent to read/write a persistent config file (default ~/.dingtalk-skills/config) via scripts/dt_helper.sh, to cache tokens, and to write multi-line task scripts to /tmp/<task>.sh and execute them. Those actions go beyond simple read-only API calls: the skill will persist secrets and run generated shell scripts. While these are functionally required for token management, they expand the runtime footprint and create opportunities for misuse if commands are constructed incorrectly or if the config is exposed.
- Install Mechanism
- okThere is no install spec (instruction-only plus one bundled helper script). No external downloads or package installs are performed. The bundled shell script is included in the skill package, so nothing is pulled from arbitrary URLs at install time.
- Credentials
- concernAlthough registry metadata lists no required env vars, SKILL.md and scripts expect and manage DINGTALK_APP_KEY and DINGTALK_APP_SECRET (required) and may use DINGTALK_MY_USER_ID and DINGTALK_CONFIG. The script also writes access tokens and secrets into a plaintext config file. Asking for app key/secret is proportionate to the stated purpose, but failing to declare them in metadata and persisting them unencrypted is a notable mismatch and risk.
- Persistence & Privilege
- noteThe skill persistently stores credentials and tokens under a per-user config file (~/.dingtalk-skills/config) and caches tokens. always:false and no cross-skill modification are fine. The persistence behavior is expected for token caching, but users should be aware credentials are stored on disk in clear form (the script attempts to mask output but does not encrypt the file). The skill also writes temporary scripts to /tmp and executes them.
