Is godsboy/garmin-connect-fixed safe?
https://github.com/openclaw/skills/tree/main/skills/godsboy/garmin-connect-fixed
This skill is a legitimate Garmin Connect fitness data integration for the Clawdbot platform, but it was published directly from a developer's personal environment without sanitization. The primary security concerns are: (1) the setup flow passes Garmin passwords as plaintext CLI arguments, exposing them in process listings and shell history; (2) hardcoded developer-specific paths (/home/mamotec/) will cause silent failures on all other systems; and (3) a persistent cron job collects sensitive biometric health data every 5 minutes into an unprotected local cache. No prompt injection, active exfiltration, or malicious code was detected, and canary files remain intact.
Category Scores
Findings (8)
HIGH Password transmitted as plaintext CLI argument -30 ▶
SKILL.md instructs users (and implicitly, agents) to invoke 'python3 scripts/garmin-auth.py [email protected] your-password'. Passing credentials as positional arguments exposes them in the process table (visible via 'ps aux' to any process on the system), in shell history files, and in system audit logs. This is a well-known credential exposure anti-pattern.
HIGH Persistent cron job installs background data collection process -18 ▶
The skill instructs adding a cron entry that executes garmin-sync.py every 5 minutes indefinitely. This creates a persistent background process that continuously authenticates to Garmin's API using stored credentials, running outside user awareness after initial setup. The cron wrapper also writes to /tmp/garmin-sync.log with no rotation.
MEDIUM Sensitive biometric health data cached without access controls -10 ▶
garmin-sync.py writes detailed biometric data including sleep quality scores, deep/REM/light sleep durations, resting heart rate, step counts, calorie burn, and detailed workout records to ~/.clawdbot/.garmin-cache.json. This file has standard user permissions (no additional ACLs) and is accessible to any process running as the same user, including other installed skills.
MEDIUM Developer PII and hardcoded paths leaked in production scripts -15 ▶
Multiple scripts contain the developer's home directory path (/home/mamotec/), personal email address ([email protected]), and absolute paths to their development environment. This indicates the skill was published from a personal development checkout without sanitization. The hardcoded paths will cause silent failures on any other system.
MEDIUM Agent credential collection workflow normalizes password exposure -20 ▶
When active in an agent context, this skill's setup flow requires the agent to obtain the user's Garmin email and password and pass them as command-line arguments. This trains users to share raw credentials with agents and creates a pattern where credential collection is treated as routine, potentially increasing susceptibility to credential harvesting by malicious skills.
LOW Canary credential files accessed during install window -8 ▶
Auditd and inotifywait both recorded OPEN+ACCESS events on honeypot files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, GCP credentials) at two timestamps (1771924817 pre-clone and 1771924834 post-install). The first access predates the git clone and is attributable to audit infrastructure initialization. The second access origin is ambiguous. All CLOSE events show CLOSE_NOWRITE, and the authoritative canary integrity check confirms no modifications or exfiltration.
LOW Script functionality broken on non-developer systems -12 ▶
garmin-cron.sh hardcodes 'cd /home/mamotec/clawd/garmin-connect-clawdbot' and garmin-auth-oauth.py hardcodes load/dump paths to /home/mamotec/.garth/. Users following the README would install to a different path, causing the cron job to silently fail without error surfacing to the user.
INFO Clone behavior normal — GitHub only, no unexpected destinations 0 ▶
Network monitoring confirmed the only external connection during installation was to 140.82.121.4:443 (GitHub CDN) for the git clone operation. No DNS queries to attacker-controlled domains, no secondary payload downloads, and no connections to data collection endpoints were observed.