Is a-suraj-bhatti/reminder-guardian safe?
https://github.com/openclaw/skills/tree/main/skills/a-suraj-bhatti/reminder-guardian
Reminder Guardian is a clean, lightweight Python skill for logging reminder entries and generating openclaw cron blueprint payloads. The skill code contains no credential file access, no network calls, and no install-time execution hooks; skill.md is free of prompt injection. The primary concerns are a hardcoded parents[3] path traversal that writes log data outside the skill directory in non-standard installs, subprocess use for a local datetime utility (safely constructed without shell=True), and user-controlled message text interpolated verbatim into cron payloads. Canary file reads detected in monitoring are attributable to the oathe audit infrastructure rather than the skill — the skill was never executed during installation and its code provably does not enumerate credential paths — with all canary files confirmed intact.
Category Scores
Findings (5)
MEDIUM Hardcoded parents[3] path traversal writes outside skill directory -20 ▶
reminder_guard.py resolves its log path by climbing three directory levels above the script: REPO_ROOT = Path(file).resolve().parents[3], then writes to REPO_ROOT/memory/reminder-log.json. This hardcodes an assumption that the skill resides exactly at
MEDIUM All six honeypot credential files opened during audit session -10 ▶
inotifywait and auditd file-access records show all six canonical credential honeypots (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, .config/gcloud/application_default_credentials.json) were opened and read twice during the session — first at audit(1771648204.566) immediately during monitoring setup, and again at audit(1771648231.901) approximately 27 seconds into the session. Both access sequences are attributed to the oathe audit infrastructure: the first batch is associated with pid=1001 (sudo, ppid=983) which is the audit orchestration process; the second batch follows the identical file enumeration pattern of a monitoring canary sweep. The skill code contains no file-reading logic targeting these paths and was never executed during installation. Post-audit canary integrity check confirms all files remain intact with no content modification or exfiltration.
LOW subprocess.run spawns local Python time helper -17 ▶
reminder_guard.py uses subprocess.run to execute time_helper.py, appending the user-supplied --offset argument as an argv element to a fixed command array. Because shell=True is not used, shell metacharacter injection is not possible. TIME_HELPER is resolved via Path(file).resolve().parents[2] / 'scripts' / 'time_helper.py', confining execution to the skill directory. time_helper.py itself performs only datetime arithmetic with no filesystem writes or network calls.
LOW User-controlled text embedded verbatim in cron blueprint payload -8 ▶
The format_blueprint function constructs the cron event payload by directly interpolating user-supplied message and note fields without sanitization. The resulting JSON is intended to be passed to 'openclaw cron add'. If the cron delivery pipeline or a downstream notification system uses an LLM to process or act on the payload text, a crafted reminder message could achieve secondary prompt injection. The skill itself does not execute the payload — it is presented to the user for manual review before scheduling.
INFO Expected HTTPS connection to GitHub during installation -12 ▶
The sole external network activity was a TLS connection to 140.82.121.3:443 (github.com) to shallow-clone the openclaw/skills monorepo and sparse-checkout the reminder-guardian skill path. This is the standard installation mechanism. No additional DNS resolutions to external hosts, no secondary download stages, and no unexpected background processes were observed.