groove-dev 0.27.26 → 0.27.28

package/README.md

@@ -7,6 +7,20 @@ The open-source orchestration layer for AI coding tools. Spawn teams of agents,
 [![npm](https://img.shields.io/npm/v/groove-dev)](https://www.npmjs.com/package/groove-dev)
 [![License](https://img.shields.io/badge/license-FSL--1.1--Apache--2.0-blue)](LICENSE)
 
+## Get Started
+
+### Download the App
+
+No terminal needed. Download, install, open a project folder.
+
+- [**macOS** (.dmg)](https://github.com/grooveai-dev/groove/releases/latest) — Intel and Apple Silicon
+- [**Windows** (.exe)](https://github.com/grooveai-dev/groove/releases/latest) — one-click installer
+- [**Linux** (.AppImage)](https://github.com/grooveai-dev/groove/releases/latest) — x64 and ARM
+
+Everything is bundled — daemon, GUI, auto-updates. No Node.js required.
+
+### Developer Install
+
 ```bash
 npm i -g groove-dev
 groove start
@@ -16,6 +30,20 @@ The GUI opens at `http://localhost:31415`. On a VPS? groove detects it and tells
 
 ---
 
+## Desktop App
+
+The desktop app is the easiest way to use groove — no terminal, no dependencies, no setup.
+
+- **Full GUI dashboard** — agent tree, chat, editor, telemetry, marketplace, all in one window
+- **Bundled daemon** — starts automatically when you open a project, stops when you close it
+- **System tray** — quick access to recent projects, daemon status, and controls
+- **Automatic updates** — new versions install silently in the background
+- **Multi-workspace** — open any project folder; manages one daemon per project
+- **Platform support** — macOS (Intel + Apple Silicon), Windows (x64 + ARM64), Linux (x64 + ARM64)
+- **No dependencies** — everything is bundled. No Node.js, no terminal knowledge needed
+
+---
+
 ## The Problem
 
 AI coding agents waste your money and lose their way:

package/SECURITY_SWEEP.md

@@ -0,0 +1,228 @@
+# Security Sweep Report
+
+Date: 2026-04-16
+Assessor: Security audit
+Scope reviewed: `../packages/desktop`, `../packages/gui`, `../packages/daemon`, root dependency graph in `../package-lock.json`
+Note: the working directory `./` only contained handoff artifacts, so the actual Electron app code audited lives in the parent monorepo `../`.
+
+## Executive Summary
+
+Overall risk: **High**
+
+The desktop app has several solid baseline controls in place — Electron windows run with `contextIsolation`, `sandbox`, and `nodeIntegration: false`; provider API keys are encrypted at rest; and file path handling includes symlink checks. However, I found **three high-impact architectural issues** that materially raise compromise risk:
+
+1. **Project-controlled active content is served from the app's trusted origin**, creating a same-origin path to the daemon API.
+2. **The daemon control plane is effectively unauthenticated**, with broad localhost trust and optional non-loopback binds.
+3. **Browser-mode marketplace tokens can be persisted in plaintext config and then exposed by `/api/config`**.
+
+These issues mean that a malicious repository, a hostile local webpage on `localhost`, or a reachable peer when bound to Tailscale/LAN can potentially read project data, mutate files, spawn processes/agents, and access local app state.
+
+## Methodology
+
+- Static review of Electron main/preload, renderer, and daemon code
+- Targeted grep for OWASP-style sinks: XSS, injection, SSRF, auth bypass, unsafe file access, shell/process execution
+- Review of secret storage and config persistence behavior
+- Dependency check with `npm audit --json` and dependency resolution via `npm ls`
+- Verification of packaging and ignore rules for runtime secrets/artifacts
+
+## Findings
+
+### 1) Critical — Untrusted project HTML/JS can execute with daemon origin
+
+**Severity:** Critical  
+**Category:** XSS / trusted-origin content execution / privilege escalation  
+**Primary locations:**
+- `../packages/gui/src/views/editor.jsx:165`
+- `../packages/daemon/src/api.js:2274`
+- `../packages/daemon/src/mimetypes.js:15`
+- `../packages/daemon/src/mimetypes.js:17`
+
+**What I found**
+- The editor intentionally previews HTML files by loading `/api/files/raw?path=...` into an iframe: `../packages/gui/src/views/editor.jsx:165`.
+- The daemon serves raw project files directly from the app origin and preserves executable MIME types such as `text/javascript` and `text/html`: `../packages/daemon/src/api.js:2274`, `../packages/daemon/src/mimetypes.js:15`, `../packages/daemon/src/mimetypes.js:17`.
+- Because this content is delivered from the same origin as `/api/*`, any project-controlled HTML that gets rendered can execute JavaScript against the daemon API using the app's trusted origin.
+
+**Why this matters**
+A malicious repository can plant an `index.html` + `payload.js` pair. If the HTML preview path is reached, or if the raw file is otherwise navigated to from the trusted origin, the payload can:
+- read or modify project files,
+- spawn/kill agents,
+- change daemon config,
+- abuse local-only features exposed over HTTP/WS.
+
+This is a classic Electron/browser trust-boundary failure: **workspace content should never run with the same origin as the privileged app UI**.
+
+**Recommended fix**
+- Do **not** serve active workspace content (`.html`, `.js`, `.mjs`, `.svg`, etc.) from the daemon's privileged origin.
+- For previews, use one of these safer patterns:
+  - render sanitized HTML only,
+  - serve previews from a **separate origin** with no access to `/api/*`,
+  - use a dedicated isolated `BrowserWindow`/partition with no preload, no shared cookies/storage, and no privileged bridge,
+  - force dangerous types to download or be served as `text/plain`.
+- Remove `allow-same-origin` from any preview iframe unless the content is fully trusted.
+- Add regression tests that verify active content cannot call privileged API routes.
+
+**Priority:** P0
+
+### 2) High — Daemon HTTP/WebSocket control plane has no real authentication
+
+**Severity:** High  
+**Category:** Authentication / access control / CSRF-adjacent localhost trust  
+**Primary locations:**
+- `../packages/daemon/src/api.js:68`
+- `../packages/daemon/src/api.js:120`
+- `../packages/daemon/src/api.js:2223`
+- `../packages/daemon/src/index.js:155`
+- `../packages/daemon/src/index.js:169`
+- `../packages/daemon/src/index.js:250`
+- `../packages/daemon/src/index.js:451`
+
+**What I found**
+- The REST API trusts requests with **no `Origin` header** and also allows **any localhost origin**: `../packages/daemon/src/api.js:68`.
+- Sensitive routes such as agent spawning and file deletion are exposed without any per-request auth token: `../packages/daemon/src/api.js:120`, `../packages/daemon/src/api.js:2223`.
+- WebSocket upgrades also allow missing `Origin`, and accepted clients can request terminal spawns/input: `../packages/daemon/src/index.js:155`, `../packages/daemon/src/index.js:169`, `../packages/daemon/src/index.js:250`.
+- The daemon can bind to non-loopback hosts, including Tailscale/LAN addresses: `../packages/daemon/src/index.js:451`.
+
+**Why this matters**
+This turns the daemon into a local control plane with weak trust assumptions:
+- Any hostile local webpage served from `http://localhost:*` can make authenticated-by-origin reads/writes against the daemon.
+- Any non-browser client can omit `Origin` entirely and still connect.
+- If the daemon is started on a reachable interface (for example Tailscale/LAN), remote peers can hit powerful endpoints unless another network control blocks them.
+
+Impact includes agent/process control, file mutation, editor/terminal access, config changes, and broader project compromise.
+
+**Recommended fix**
+- Require a **random per-instance bearer token** (or equivalent secret) for **all** HTTP and WebSocket traffic.
+- Reject requests lacking that token, even from localhost.
+- Narrow CORS to the exact GUI origin instead of `any localhost port`.
+- Treat missing `Origin` as untrusted for browser-like endpoints.
+- For non-loopback binds, require explicit auth plus network ACLs/TLS.
+- Consider Unix domain sockets or loopback-only ephemeral tokens for desktop mode.
+
+**Priority:** P0
+
+### 3) High — Marketplace token can be stored plaintext and leaked through `/api/config`
+
+**Severity:** High  
+**Category:** Secrets management / sensitive data exposure  
+**Primary locations:**
+- `../packages/daemon/src/skills.js:47`
+- `../packages/daemon/src/skills.js:80`
+- `../packages/daemon/src/firstrun.js:145`
+- `../packages/daemon/src/api.js:3438`
+- `../packages/daemon/src/api.js:1115`
+
+**What I found**
+- The browser-style auth callback stores `marketplace.token` inside `daemon.config`: `../packages/daemon/src/api.js:1115`, `../packages/daemon/src/skills.js:80`.
+- `saveConfig()` writes that config directly to `config.json` without encryption: `../packages/daemon/src/firstrun.js:145`.
+- `/api/config` returns the full config object without redaction: `../packages/daemon/src/api.js:3438`.
+
+**Why this matters**
+Even though the Electron main process uses encrypted `safeStorage` for its own desktop token path, the daemon still contains a second browser-oriented auth flow that can persist a bearer token in plaintext config and then expose it over the local API.
+
+If an attacker can hit the daemon API or read the `.groove` directory, they may recover the marketplace token and impersonate the user against Groove services.
+
+**Recommended fix**
+- Never persist auth/session tokens in `config.json`.
+- Store marketplace/session tokens only in OS-backed secure storage.
+- Redact sensitive config keys from `/api/config` before returning any response.
+- Add a migration that strips existing `marketplace.token` values from historical configs.
+
+**Priority:** P1
+
+### 4) Medium — Renderer can trigger arbitrary external URLs for integration OAuth
+
+**Severity:** Medium  
+**Category:** URL handling / privilege amplification  
+**Primary location:**
+- `../packages/desktop/main.js:1004`
+
+**What I found**
+`integration-oauth-start` accepts an arbitrary `oauthUrl` from the renderer and passes it straight to `shell.openExternal()`.
+
+**Why this matters**
+By itself this requires renderer compromise, but in Electron this is still an important defense-in-depth boundary. If the renderer is ever compromised, an attacker can launch:
+- arbitrary external websites,
+- custom protocol handlers,
+- local application handlers registered on the OS.
+
+**Recommended fix**
+- Validate `oauthUrl` against a strict allowlist derived from the integration registry.
+- Allow only `https:` and known IdP domains.
+- Deny custom schemes and `file:`/`javascript:`/unexpected handlers.
+
+**Priority:** P2
+
+### 5) Medium — Electron auto-approves all permissions for localhost content
+
+**Severity:** Medium  
+**Category:** Least privilege / hardening gap  
+**Primary location:**
+- `../packages/desktop/main.js:245`
+
+**What I found**
+The permission handlers explicitly allow microphone/media, but then also return `true` for any other permission as long as the requesting page is `localhost`/`127.0.0.1`.
+
+**Why this matters**
+Once renderer trust is broken, this widens impact by silently approving extra capabilities that were never intended for routine app operation.
+
+**Recommended fix**
+- Replace the implicit `allow all localhost permissions` behavior with an explicit allowlist.
+- Deny by default.
+- Log and review any denied permission requests during development.
+
+**Priority:** P2
+
+### 6) Moderate dependency advisory — `follow-redirects` header leak
+
+**Severity:** Moderate  
+**Category:** Dependency / third-party risk  
+**Location:** transitive dependency path `@groove-dev/daemon -> @slack/bolt -> axios -> follow-redirects@1.15.11`
+
+**What I found**
+A fresh `npm audit --json` run on 2026-04-16 reported one advisory:
+- `follow-redirects <= 1.15.11` — leaks custom authentication headers to cross-domain redirect targets.
+
+Dependency resolution shows this arrives through:
+- `@slack/bolt@4.7.0`
+- `axios@1.15.0`
+- `follow-redirects@1.15.11`
+
+**Recommended fix**
+- Upgrade to a dependency chain that pulls a fixed `follow-redirects` release.
+- If immediate upgrade is blocked, audit all Slack/axios usage for redirect-following with sensitive headers.
+
+**Priority:** P2
+
+## Positive Controls Observed
+
+These are good and worth keeping:
+
+- Electron windows use `contextIsolation: true`, `nodeIntegration: false`, and `sandbox: true`: `../packages/desktop/main.js:227`
+- Provider credentials are encrypted at rest with AES-256-GCM and `0600` file permissions: `../packages/daemon/src/credentials.js:1`
+- File path validation checks traversal and resolves symlinks before access: `../packages/daemon/src/api.js:2021`
+- The root ignore policy excludes `.env`, `.groove`, runtime bundles, and build artifacts from git: `../.gitignore:1`
+- I did **not** find hardcoded secrets in tracked source during pattern scans.
+
+## Remediation Plan
+
+### Immediate (this week)
+- Disable HTML preview or force dangerous file types to render as plain text/download.
+- Add an auth token requirement to all daemon HTTP/WS endpoints.
+- Redact `/api/config` and remove token persistence from daemon config.
+- Patch the `follow-redirects` dependency chain.
+
+### Short term
+- Serve untrusted previews from a separate origin/partition.
+- Tighten `shell.openExternal()` to strict allowlists only.
+- Replace localhost-wide CORS trust with an exact-origin model.
+- Lock Electron permission handling to a minimal explicit list.
+
+### Verification to add after fixes
+- Test that opening a repo-controlled HTML file cannot call `/api/agents`, `/api/files/*`, or `/api/config`.
+- Test that requests without the daemon auth token fail for both REST and WS.
+- Test that `/api/config` never returns secret-bearing fields.
+- Re-run `npm audit --json` after dependency upgrades.
+
+## Bottom Line
+
+The app already has several good Electron hardening defaults, but the **same-origin preview design** and the **unauthenticated daemon control surface** currently dominate the risk profile. I would treat Findings 1 and 2 as release-blocking for environments where untrusted repositories or shared/local-network access are realistic.