← 回到四專案比較

獨立審查 · 完整回覆

Orca

Orca · Codex · 讀取安全程式碼

2026-10-227a06b6579 ↗僅讀公開網路

確切題目

Is there a security risk in installing this tool? Read the security-related code in this repository and understand its encryption and data transmission mechanisms before answering. If a mechanism cannot be verified from the accessible code, say so.
題目附帶的固定版本連結 ↗

下方完整保留 agent 原始回覆，原文語言有明確標示。中文導讀是編輯整理，不是原文，也不是驗證結論。審查沒有執行安裝或攻擊測試。

中文導讀（編輯整理）

確認 v2 加密與重播防護；另指出可讀推播內容、未加密金鑰檔與擴大的網路暴露。

實際閱讀範圍：RPC 範圍、密碼學／金鑰派生／訊框、socket 接線、推播、金鑰儲存、遙測與診斷。

下載完整英文原文 · SHA-256 302fd5aadfa00b18756a5d1aca49af3381403a8f38a60c33faa2c82929f3f36c

完整英文原始回覆（未翻譯）

Yes—there are meaningful security and privacy risks. I would treat Orca as a trusted remote-development application with access to your user account, and would not install it directly on a machine holding sensitive credentials without isolation. I found real encryption and authentication controls, but they do not protect every data path.

This assessment covers accessible source at commit 7a06b6579bbd106b0cb9bb53978f2cacc7326b9f. It is a static code review; I did not execute the installer or verify a released binary.

  1. Remote access has substantial privileges. The code explicitly defines workspace access as the ability to run commands as the host’s user. Paired runtime clients also receive account, settings, skills, and host administration permissions; desktop control requires an additional grant. A compromised authorized client can therefore have serious consequences even when encryption works correctly. Permission definitions, caller permissions

  2. The remote RPC encryption is implemented, rather than merely claimed. The shared primitives use TweetNaCl box.before and authenticated encryption. Version 2 derives separate directional keys using HKDF-SHA256, binds them to a handshake transcript and fresh nonces, and checks session identifiers and sequential counters. These are useful protections against tampering and replay. Crypto primitives, key derivation, frame verification

    Relay connections require version 2 and authenticate the device inside the encrypted channel, additionally checking its identity against the relay connection. Direct connections still support legacy framing, which lacks the explicit session/counter replay checks present in v2. This is a protocol limitation, not a demonstrated authentication bypass. Socket wiring, channel implementation

  3. Push notification contents are readable by the push gateway. Notification titles, bodies, worktree identifiers, and agent state are serialized into JSON and sent to /v1/send. They are not encrypted end to end with the phone in this path. The dispatcher clips titles to 80 characters and bodies to 180; clipping is not secret redaction. Sensitive text appearing in a notification could therefore leave your machine in readable form at the service endpoint. Notification payload construction, gateway transmission

  4. The desktop E2EE private key is not encrypted at rest. It is stored as base64 in JSON. The file helper applies Unix 0600 permissions and Windows ACL restrictions, but those protect access rather than encrypt the contents. Malware running as your user, or someone obtaining an accessible backup, could read the key. The keypair writer also does not check the helper’s boolean result indicating whether permission restriction succeeded. Key storage, file protection

    A separate secret-storage adapter uses Electron’s OS-backed safeStorage. That does not establish that every credential or local record is encrypted; its own protection reporting acknowledges unavailable or weak keyring configurations. I could not verify every credential persistence path. Secret-storage adapter

  5. Pairing expands network exposure. Ordinary desktop startup configures the WebSocket listener for loopback initially. Creating a mobile pairing offer widens it to all interfaces—even when selecting local-only pairing. The LAN transport uses plain HTTP/WebSocket with application-layer encryption above it. Authentication remains necessary, but the listener becomes reachable by other machines. Startup configuration, pairing behavior, transport

  6. There are additional outbound data paths. Official builds can send consent-gated usage events to PostHog over HTTPS, including persistent installation ID, session ID, and OS/app information. Opting out through the UI deliberately sends one opt-out event. Diagnostics have a separate upload mechanism; uploaded bundles are readable by the receiving service. Telemetry transport, diagnostic upload

What remains unverified: the cloud API/authentication services are explicitly in a private repository. I cannot verify their implementation, production retention/access controls, or whether deployed services match this source. I also did not establish released-binary equivalence, complete dependency safety, or the full updater verification chain. Source installation executes a postinstall build/native-rebuild process, so installing dependencies is itself code execution. Cloud source boundary, installation scripts

My recommendation is to evaluate it in a VM or separate OS account with disposable repositories and narrowly scoped credentials. Keep mobile pairing and push notifications disabled initially. For confidential work, the readable notification path and private cloud components require particular scrutiny. Nothing I inspected proves malicious intent, but the accessible code does not justify calling the tool unconditionally safe.

Fixed but not yet released (awaiting review): Nothing.

← 回到比較表