← 回到四專案比較

獨立審查 · 完整回覆

Clawdline v2.1.3

Clawdline v2.1.3 · Claude Code · 讀取安全程式碼

2026-10-22fcc905914 ↗僅讀公開網路

確切題目

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 原始回覆，原文語言有明確標示。中文導讀是編輯整理，不是原文，也不是驗證結論。審查沒有執行安裝或攻擊測試。

中文導讀（編輯整理）

在來源摘要辨識到標準加密、重播檢查、配對與 HTTP 防護；提醒端點權限、金鑰檔、網站程式碼與供應鏈信任。未審查瀏覽器與 Swift 來源。

實際閱讀範圍：透過網頁摘要閱讀安裝、Go 加密／配對／重播、金鑰檔與 HTTP 防護；未驗證瀏覽器密碼學、Swift 橋、setup 或發行執行檔。

這是固定來源 fcc905914 與 v2.1.3 發行頁 的有限公開網路審查，不是安全證書。未執行安裝、攻擊測試或二進位驗證，也未檢查私有 Cloud 正式部署。公開目錄／資產讀取部分失敗；Claude 的網頁擷取可能只提供摘要。未閱讀的機制或推測不能當成已確認漏洞。

固定來源的 README 當時仍選 v2.1.2，這是審查當時的真實觀察；後來主線 9e5a7ad 已改為 v2.1.3。本輪未審查 Swift 原生配對橋，不能用它宣稱先前 2.1.1 專項報告的疑慮已解決。上一輪 v2.1.2 回覆保留供對照。

方法：只給公開來源／發行網址與問題，停用儲存庫脈絡；可見工具紀錄僅有網路讀取。Codex 首次因工具未提供網路而技術失敗，排除比較後各重試一次；有效回覆完整保留，包括原文的狀態結尾，不宣稱所有內建指令均已移除。完整方法紀錄。

下載完整英文原文 · SHA-256 01e81e2af355d84a29c0ec3896b96fee16e9161a1e656a42d9c3ca597916b200

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

Verdict: I found no sign of malicious or deceptive behaviour, and the cryptography is built from standard parts. Installing it is not risk-free, though. The tool can read your Claude Code and Codex conversations, your project files and your terminals. It can also type commands into those terminals. Most of the risk comes from what that access allows if something goes wrong, not from a broken cipher.

How I checked: I read the source at commit fcc9059 (the commit release v2.1.3 points to) through GitHub’s web pages. My fetch tool summarizes pages, so I read summaries rather than full files. I did not download, run or verify any binary.

What the code confirms

Installer (install.sh)

  • It checks the release manifest’s Ed25519 signature against one public key hardcoded in the script (2Du3yZ4j…/O0=), using OpenSSL 3 and Python run in isolated mode (-I).
  • Only after that check passes does it compare the archive’s SHA-256 hash and size. Then it unpacks into ~/.local/share/clawdline-next with private file permissions.
  • It never uses sudo and never pipes a download straight into a shell. The background service is created afterwards by the downloaded clawdline setup binary, whose code I did not review.

Encryption of Cloud traffic (internal/domain/cloud/envelope.go)

  • Message contents are encrypted with AES-256-GCM, using a fresh 12-byte random nonce from crypto/rand for each message.
  • Each message is signed with the sending device’s Ed25519 key. The receiver rejects senders it hasn’t already pinned and checks the signature before decrypting.
  • Replay protection works. The inbound path in internal/adapters/cloud/transport.go runs: signature check → replay-window check (Replay.Claim) → decrypt.

Pairing a phone or browser (internal/domain/cloud/pairing.go)

  • The two sides agree a key with X25519, which feeds an HKDF-SHA256 key derivation. The resulting key encrypts the handover with AES-GCM, and the authenticated data covers the pairing ID, the sender and the temporary public key.
  • The browser’s offer is encrypted with a 32-byte secret carried in the QR code or link. The server stores only a hash of that secret.
  • On this design, the relay can’t read or quietly alter a pairing.

Key storage (internal/adapters/cloudkeys/files.go)

  • Keys are stored as plain base64 in files under …/cloud/. The directory is owner-only (0700) and the files are 0600. Writes are atomic, and opens refuse symlinks (O_NOFOLLOW plus a same-file check).
  • The keys are not encrypted at rest. Any program running as your user can read them, and the macOS Keychain is listed as planned but not built.

Local web server (internal/transport/http/gate.go, docs/remote.md)

  • It binds to 127.0.0.1 by default. It only accepts requests addressed to localhost or your Tailscale name, which defends against DNS-rebinding attacks.
  • Cross-site requests are blocked using the Origin and Sec-Fetch headers and by requiring JSON bodies.

Risks and weak points

  1. A paired device controls your machine. A device with “read+send” permission can type into your terminals, and new pairings default to read+send. Anyone who sees a pairing link or QR code before you use it can pair instead of you. The same applies to a clawdline open URL, which contains a full access token.
  2. The web console’s code comes from the vendor’s server. The phone/browser viewer at app.clawdline.com is loaded from Cloudflare Pages. Nothing like code signing or Subresource Integrity checks what gets served (docs/hosted-console.md). A compromised or malicious deployment could change the code that holds your keys. That weakens the claim that “the relay only carries ciphertext”: you are still trusting whoever runs the website.
  3. Trust in the release process. The release signing key is a GitHub Actions secret, gated behind an environment: release approval. Whoever controls the maintainer’s GitHub account and that secret can ship a validly signed update. Several actions are pinned to version tags rather than exact commits. The project itself says releases are not yet reproducible.
  4. Metadata isn’t hidden. It encrypts content but not the message envelope. The Cloud relay sees your account, devices, channels (which include machine and session IDs), timing, message sizes and IP address. STUN servers at Cloudflare and Google see your IP when a direct connection is attempted. Even with Cloud off, it contacts app.clawdline.com/BUILD.json and GitHub for update checks.
  5. Smaller issues:
    • The envelope’s metadata is bound only by the signature (encryption covers no associated data), and there is no timestamp freshness check.
    • The cookie gets the Secure flag based on a header the client controls (X-Forwarded-Proto).
    • The recovery code is the raw content key.
    • Some design docs are out of date. docs/cloud-wire.md says the Go pairing and replay protection aren’t implemented, but the code has both.

What I couldn’t verify

  • The binaries. I didn’t download any. Whether the v2.1.3 tarballs or DMG match this source, the Sigstore/SLSA attestations, notarization and SHA256SUMS are all unchecked.
  • The Clawdline Cloud servers (relay and API). They are closed source, so their logging, retention and deployed configuration are unknown.
  • The browser-side crypto (web/) and how the browser stores keys.
  • Swift code. I listed the macOS app’s code in shell/darwin/ but didn’t review it. The files the docs name (CloudEnvelope.swift, CloudKeys.swift) didn’t appear in that partial listing.
  • Other code paths. I didn’t review clawdline setup (the service it installs), the auto-updater, push notifications, or the constant-time token comparison in auth.
  • The installer pin. The README’s install command still pins v2.1.2, not v2.1.3.

Recommendations if you install

  • Use local-only mode (Cloud is off by default).
  • Pair only your own devices, and choose read-only unless you need to send.
  • Revoke devices you no longer use.
  • Before running anything, check the attestation with gh attestation verify <file> --repo sainteye/clawdline.

My web searches turned up nothing about Clawdline, only the unrelated OpenClaw project, so I have no outside reputation information.

Sources:

← 回到比較表