@dura-run/cli 0.2.1 → 0.3.1

package/README.md

@@ -41,6 +41,46 @@ dura deploy
 
 All project-scoped commands pick up `projectId` from `dura.json` — you only need `--project <id>` when running outside a project directory.
 
+## Security
+
+### `dura dev` runs your handlers in-process (GH #118)
+
+Until we wire isolated-vm into the local runner, `dura dev` loads your
+automation code via native `import(...)` in the CLI's Node process. That
+process has full access to your filesystem — including `~/.dura/config`
+(where the CLI stores your API key), `~/.ssh`, `~/.aws`, and environment
+variables. A malicious npm dependency anywhere in your handler's import
+graph could read those files and exfiltrate them on the first request.
+
+To make this risk explicit, `dura dev` refuses to start whenever you
+have credentials stored locally unless you opt in per project:
+
+```bash
+# Option 1 — pass --trust (recommended; acknowledges the risk once)
+dura dev --trust
+
+# Option 2 — set an env var (useful in scripts / devcontainers)
+DURA_DEV_TRUST=1 dura dev
+
+# Option 3 — log out first (removes the credentials being protected)
+dura logout
+dura dev
+```
+
+Acceptance is recorded in `.dura/dev-trust` inside your project, so
+subsequent runs proceed without re-prompting. The warning banner is
+still printed each time as a reminder. Delete `.dura/dev-trust` to
+revoke trust for the project. Add the file to `.gitignore` if you
+don't want to share your acceptance with collaborators.
+
+Treat `dura dev` with the same trust you'd give `node -e ...` in a
+project that imports every one of your dependencies — audit your
+`package.json` (and lockfile) before trusting a new project.
+
+We're tracking a full isolated-vm migration for local dev in
+[GH #147](https://github.com/dura-run/dura-run/issues/147) — once
+that ships, the trust gate will be removed.
+
 ## Documentation
 
 Full docs and recipes at [docs.dura.run](https://docs.dura.run).