Is dgorissen/stormglass safe?
https://github.com/openclaw/skills/tree/main/skills/dgorissen/stormglass
The dgorissen/stormglass skill is a clean, purpose-built Python surf conditions fetcher with no adversarial content, no hidden behaviors, and a zero-dependency stdlib-only implementation. All network activity during operation is limited to declared HTTPS endpoints (Stormglass, Google Geocoding, OpenStreetMap), credentials are handled conventionally via environment variables, and the SKILL.md contains no prompt injection patterns. The only notable observations are: platform-level canary file reads by the OATHE scanner (confirmed non-exfiltrative), expected API key transmission to documented third-party services, and the OpenClaw gateway's own post-install AWS connections which are unrelated to the skill itself.
Category Scores
Findings (6)
INFO API keys transmitted to declared third-party services -5 ▶
STORMGLASS_API_KEY is sent as an HTTP Authorization header to api.stormglass.io weather and tide endpoints. GOOGLE_GEOCODING_API_KEY is included as a query parameter to maps.googleapis.com. Both are explicitly declared in skill metadata under requires.env and documented in the credential matrix. This is expected, standard API authentication behavior with no indication of key misuse.
INFO Canary file reads logged but attributable to platform scanner -7 ▶
Auditd PATH records show read-only access to .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and gcloud credentials at 1771912618.486 (before skill clone begins at 1771912636) and again at 1771912641.554 (5s after install completes). No file-reading code exists anywhere in the skill's Python scripts. Canary integrity check explicitly confirms no exfiltration occurred. Pattern is consistent with OATHE's own pre/post-install file inventory scans.
LOW OpenClaw gateway establishes persistent outbound connections post-install -10 ▶
The post-install connection diff shows the openclaw-gateway process (pid=1095) establishing ESTAB TCP connections to 34.233.6.177:443 (AWS EC2 IP range) on two sockets and opening listening ports on localhost 18790 and 18793. This is consistent with the OpenClaw agent platform's own infrastructure rather than the stormglass skill, but represents a persistent network surface opened within the installation window that should be understood by the deployer.
LOW User-Agent header discloses skill identity and platform to OpenStreetMap -5 ▶
The OSM Nominatim fallback geocoding code sends a User-Agent of 'stormglass-surf-skill/1.0 (+openclaw-cron)' to the public OpenStreetMap API. While OSM's terms of service require a descriptive User-Agent, this header discloses the skill name, version, and OpenClaw platform identifier to a third-party public service on every location lookup that lacks a Google API key.
INFO Zero external package dependencies eliminates supply-chain risk 0 ▶
All three Python scripts (surf_report.py, test_surf_report.py, normalize_surf_data.py) import exclusively from the Python standard library. There is no requirements.txt, no setup.py, no pyproject.toml, and no package.json. This design choice eliminates the entire class of dependency-confusion and malicious package risks.
INFO SKILL.md agent handoff rules are operationally benign 0 ▶
The skill's agent handoff section instructs: prefer --output json, treat null metrics as missing not zero, read reference.md for field details, use test script before cron rollout. All instructions are narrowly scoped to correct API usage and do not attempt to redirect agent behavior, access additional resources, or override system-level instructions.