clawdex-mobile 1.0.0

package/services/rust-bridge/Cargo.toml

@@ -0,0 +1,14 @@
+[package]
+name = "codex-rust-bridge"
+version = "0.1.0"
+edition = "2021"
+
+[dependencies]
+axum = { version = "0.8", features = ["ws", "http1", "tokio"] }
+base64 = "0.22"
+chrono = { version = "0.4", features = ["clock", "serde"] }
+futures-util = "0.3"
+serde = { version = "1", features = ["derive"] }
+serde_json = "1"
+shlex = "1"
+tokio = { version = "1", features = ["full"] }

package/services/rust-bridge/package.json

@@ -0,0 +1,13 @@
+{
+  "name": "@codex/rust-bridge",
+  "version": "0.1.0",
+  "private": true,
+  "scripts": {
+    "dev": "cargo run",
+    "start": "cargo run --release",
+    "build": "cargo build --release",
+    "typecheck": "cargo check",
+    "lint": "cargo fmt --check",
+    "test": "cargo test"
+  }
+}

package/services/rust-bridge/security_best_practices_report.md

@@ -0,0 +1,24 @@
+# Executive Summary
+The bridge exposes powerful RPC surface (terminal execution, git operations, approvals) with minimal automation around authentication, token handling, and child-process resilience. Without tightening the gates, an attacker on the same LAN can run commands or mutate the repository, and outages may go unnoticed. The following findings prioritize these risks and note the lack of tests that would otherwise guard against regressions.
+
+## Severity: High
+### HF-1 — Unauthenticated bridge surface with common dev flags
+- **Impact:** When `BRIDGE_ALLOW_INSECURE_NO_AUTH=true` and the host is bound to `0.0.0.0`, any LAN client can connect to `/rpc` and call `bridge/terminal/exec`, `bridge/git/*`, or even forward arbitrary App Server RPCs, effectively running shell commands and mutating the repository as the bridge user. This is a remote code execution and repo integrity risk.
+- **Observation:** `BridgeConfig::from_env` only skips the `BRIDGE_AUTH_TOKEN` requirement when `BRIDGE_ALLOW_INSECURE_NO_AUTH` is true (src/main.rs:51-129). `ws_handler` accepts any socket once `is_authorized` returns true, and that function returns true whenever authentication is disabled (src/main.rs:1125-1144). The powerful operations behind `handle_bridge_method` remain exposed without additional checks (src/main.rs:1307-1405).
+- **Remediation:** Require a token for any non-local binding or refuse to listen on `0.0.0.0` when auth is disabled. Alternatively, keep `BRIDGE_ALLOW_INSECURE_NO_AUTH` but automatically bind to `127.0.0.1` and refuse the flag otherwise, or fail fast if the flag is set without a token plus documented justification. Harden `bridge/terminal/exec` and `bridge/git/*` with explicit policy guards when auth is missing.
+
+## Severity: Medium
+### MF-2 — Query-token auth leaks credentials in plaintext URLs
+- **Impact:** `BRIDGE_ALLOW_QUERY_TOKEN_AUTH` accepts the token as a `token` query parameter (src/main.rs:101-129, 1125-1144). Passing secrets in URLs risks leakage through proxy logs, browser history, and any MITM on the local network (the bridge already speaks plain HTTP/TCP). A leaked token allows the exact same RPC surface as a Bearer header, so attackers can replay it.
+- **Observation:** `is_authorized` unconditionally trusts the `token` query value when the flag is true (src/main.rs:101-129). `ws_handler` populates that query into the check every WebSocket upgrade (src/main.rs:1125-1144).
+- **Remediation:** Deprecate `BRIDGE_ALLOW_QUERY_TOKEN_AUTH`; accept only Authorization headers and keep them out of URLs. If the flag is still needed, require TLS + short-lived tokens and actively rotate/log reuse.
+
+### MF-3 — App server child death leaves future requests dead and health endpoint blind
+- **Impact:** When the `codex app-server` child exits, the bridge logs the exit, fails outstanding RPCs, and shuts down approval state, but it never restarts the child or marks `/health` as degraded. Forwarded requests still attempt to write to the closed pipe and immediately fail with `-32000`, leaving clients blind and requiring a manual restart, which is a resiliency issue with moderate to high operational impact.
+- **Observation:** `spawn_wait_loop` just logs success/error and clears `pending` state without recovery (src/main.rs:362-403). `forward_request` continues to accept work and only reports failure once `write_json` fails, so the bridge does not short-circuit new requests once the child is gone (src/main.rs:406-439). The existing `/health` handler never observes the child state (src/main.rs:1117-1123).
+- **Remediation:** Monitor the app server child, surface its state through `/health`, and attempt automatic restart/backoff or block forwarded requests (return `ServiceUnavailable`) until recovery. Consider wiring `AppState` with a flag that short-circuits `handle_client_message` whenever the child is not running.
+
+### MF-4 — No automated tests for critical security gates or bridge resiliency
+- **Impact:** The bridge’s only source file is `src/main.rs` and `Cargo.toml` defines no `[dev-dependencies]` or test harnesses (Cargo.toml:1-13), so there are no unit or integration tests for `BridgeConfig`, `TerminalService`, or `AppServerBridge`. Any refactor can silently break auth, token parsing, or terminal-command restrictions, and there is no automated guard detecting the regression.
+- **Observation:** `src/main.rs` does not contain any `#[cfg(test)]` modules or `mod tests`, and there is no `tests/` directory in the repo. The mission-critical entry points (`BridgeConfig::from_env`, `TerminalService::execute_shell`, `AppServerBridge::forward_request`) are therefore unverified.
+- **Remediation:** Add tabletop unit tests that cover config parsing (including `BRIDGE_ALLOW_INSECURE_NO_AUTH` vs. `BRIDGE_AUTH_TOKEN`), query token acceptance, terminal command whitelists, and app-server shutdown behavior. Start simple with `#[cfg(test)]` modules shipping assertion scenarios, then expand to integration or smoke tests to exercise `/rpc` and `/health` flows.