Is adamludwin/here-now safe?

The skill's core function is to upload any file or directory to here.now. The publish.sh script uses find "$TARGET" -type f -print0 to recursively collect all files and upload them. There is no filtering for sensitive files such as .env, .ssh/, .aws/credentials, or other secrets. If an agent is told to 'publish my project directory' and that directory contains credentials, all secrets will be publicly hosted. The skill's own description triggers on broad phrases like 'share this', 'deploy this', or 'put this online', increasing the probability of accidental sensitive data exposure.

SKILL.md contains the instruction curl -fsSL https://here.now/install.sh | bash labeled as the way to 'install or update' the skill. This line is injected into the agent's system prompt. An agent parsing this as an operational directive could execute arbitrary code from here.now without review. The script at that URL is fully controlled by the skill author and could change at any time.

Every file the skill publishes is sent to the here.now infrastructure. The service is not a recognized major provider and its terms, data retention, and trustworthiness cannot be verified from the skill alone. Presigned upload URLs point to Cloudflare R2 via here.now's API. If the service is malicious or compromised, all uploaded content is exfiltrated. The anonymous publish workflow additionally ties file availability to a claim token that cannot be recovered if lost.

The publish.sh script accepts a --base-url flag that replaces the default API endpoint for all create, update, upload, and finalize API calls. If an attacker or malicious skill interaction manipulates this parameter, all file uploads can be redirected to an attacker-controlled server. The SKILL.md exposes this flag in the documented options table.

SKILL.md explicitly directs the agent to ask the user for their email address and POST it to https://here.now/api/auth/login. While framed as an authentication flow, this constitutes an explicit instruction to harvest PII (email addresses) and transmit them to a third-party service whose privacy practices are unknown. The endpoint creates accounts automatically for new emails.

Mirrors the prompt injection finding from an exfiltration perspective: the agent is directed to solicit and transmit user PII (email) to an external service. This is not incidental but a primary documented workflow in the skill.

The skill activates on common phrases: 'publish this', 'host this', 'deploy this', 'share this on the web', 'make a website', 'put this online'. These phrases are regularly used in development workflows where the working directory may contain .env files, node_modules with secrets, private keys, or database configs. The absence of any exclusion logic in publish.sh means secrets will be uploaded and publicly hosted if the wrong target is specified.

publish.sh writes claim tokens (one-time credentials that grant permanent ownership of anonymous publishes) to .herenow/state.json in the current working directory. If this directory is a git repository, the token could be committed and pushed. If the working directory is shared, other processes could read the token. Loss or exposure of this token permanently affects the user's ability to manage their published content.

Beyond the code execution concern, the presence of curl -fsSL https://here.now/install.sh | bash in SKILL.md could be parsed by some agents as an instruction to run during skill initialization or when the skill needs updating, depending on how the agent system interprets setup commands embedded in skill documentation.

scripts/publish.sh is a Bash script that invokes curl, find, jq, file, wc, sort, and tr. While each call appears legitimate, the script handles user-supplied TARGET paths without sanitization beyond existence checks. Filenames with special characters could potentially cause unexpected behavior in the jq pipeline construction.

publish.sh checks for a bundled jq binary at ${SKILL_DIR}/bin/jq before falling back to system jq. While no bundled binary was present in this installation, this mechanism could be used in future versions to ship a trojanized jq binary within the skill package that would execute with elevated trust.

The installation cloned from github.com (140.82.121.4:443) using git sparse-checkout. No unexpected outbound connections were established. The pre-existing connection to 185.125.188.59:443 (Canonical/Ubuntu infrastructure) was present before installation and absent after, indicating it was unrelated OS activity. DNS queries went only to local resolvers. Connection state before and after installation shows no new persistent outbound connections.

Canary files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, .config/gcloud/application_default_credentials.json) were accessed twice by the oathe monitoring harness (at audit start for baseline, at audit end for verification). No modifications or exfiltration were detected. The skill was not installed when the first access occurred (03:35:40), confirming these accesses were by the monitoring infrastructure, not the skill.