Skill flagged — suspicious patterns detected
ClawHub Security flagged this skill as suspicious. Review the scan results before using.
env-secure-manager
v1.0.1Secure environment variable & secret management with AES-256 encryption, auto-redaction, permission control, prevent credential leakage
⭐ 0· 242·0 current·0 all-time
by@ayalili
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
medium confidencePurpose & Capability
Name/description (AES-256 secret storage, redaction, permissions) align with the included code: the module encrypts/decrypts values, redacts secrets from text, and can load environment variables. However SKILL.md claims 'lightweight no dependencies' yet the code imports zod and std modules from deno.land; also the metadata declares no required env vars but the code reads/writes an OPENCLAW_ENV_ENCRYPTION_KEY environment variable.
Instruction Scope
The SKILL.md documents loadFromEnv, set/get/redact actions, which matches code. But the implementation reads Deno.env.toObject() (iterates process environment) and will set Deno.env.set('OPENCLAW_ENV_ENCRYPTION_KEY', ...) when auto-generating a key. The metadata did not declare that the skill will read or write environment variables. Reading all env entries (even though it filters by prefix) and writing a process env variable are broader scopes than the registry metadata indicates.
Install Mechanism
No install spec in registry, but the code includes remote imports from deno.land (zod and std modules). Fetching runtime dependencies from deno.land is common for Deno but it means remote code will be downloaded/executed at runtime — moderate supply-chain risk compared to fully local code.
Credentials
The skill declares no required env vars, yet init() will read OPENCLAW_ENV_ENCRYPTION_KEY and may write it to the process environment. loadFromEnv iterates the entire environment (via Deno.env.toObject()) and will import keys with a given prefix. This behavior is proportionate to a secret manager only if callers expect the skill to access process env; but that access is not declared and could expose many environment variables if the prefix is broad or changed.
Persistence & Privilege
The skill does not request 'always:true' and does not modify other skills. It does call Deno.env.set to persist the auto-generated encryption key into the process environment, which changes runtime state and could influence other components. This is not necessarily malicious but is a persistence/side-effect the user should be aware of.
What to consider before installing
This skill is plausibly what it claims to be, but there are a few red flags and bugs you should consider before installing: (1) the code reads and writes process environment variables (OPENCLAW_ENV_ENCRYPTION_KEY and loadFromEnv reads the environment). If you don't want the skill to access your environment, do not enable it. (2) The module fetches dependencies from deno.land at runtime — review those remote packages or run in an environment with restricted network access. (3) There is a likely implementation bug: loadFromEnv spreads the encrypt() result but doesn't set the stored 'value' field correctly, which can cause runtime errors or unexpected behavior. (4) Prefer providing an explicit encryptionKey when initializing rather than relying on auto-generated keys that the skill writes into the process env. (5) Test this in an isolated workspace (or with non-production secrets) and review/modify the source if you need stricter guarantees (for example, restrict env access or remove Deno.env.set). If you want me to, I can point to the exact lines with the bug and propose a corrected code snippet.Like a lobster shell, security has layers — review code before you run it.
latestvk970cv0s2gekqa2wgrxtexcef182mg1k
License
MIT-0
Free to use, modify, and redistribute. No attribution required.