Clawdline v2.1.3

中文導讀（編輯整理）

辨識到 Go／瀏覽器加密、配對、網路預設值與存取防護；剩餘疑慮包括端點入侵、金鑰檔與正式環境撤銷保證。未驗證執行檔與私有 Cloud。

實際閱讀範圍：固定原始檔中的 Go／瀏覽器密碼學、配對、設定／Relay、金鑰檔、安裝、HTTP／auth 與換鑰／資料流文件；部分列表失敗，未執行程式。

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

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

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

下載完整英文原文 · SHA-256 f93cb86ce57034cdc80d9d70d98f139cb7055bfe2bf8d55b85dbaf887d8f70c5

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

Bottom line

Yes—there is meaningful security risk, principally because Clawdline is a remote-control tool with access to sensitive developer data. The accessible code implements real encryption, not merely HTTPS with an “end-to-end encrypted” label. However, I cannot certify the v2.1.3 download or the production Cloud service as safe.

My assessment: potentially reasonable for a personal development machine with careful configuration; insufficiently verified here for an unrestricted installation on a machine holding production credentials or confidential work.

I reviewed security-relevant source at commit fcc9059142485514d54683adb769710abb96e1ab, not just the README.

Encryption and transmission

What I could verify in code

• Content encryption: Go’s Seal encrypts payloads with AES-256-GCM, using fresh 12-byte nonces from crypto/rand by default and a 16-byte authentication tag.
• Sender authentication: Envelopes receive Ed25519 signatures covering ciphertext and routing fields. Open verifies the signature against the sender’s pinned public key before decrypting. The sender identifier itself is not signed; its binding depends on that pinned-key lookup.
• Browser implementation: The browser likewise uses WebCrypto AES-GCM and Ed25519, verifies before decrypting, and generates random nonces. These are substantive implementations of endpoint encryption. Go encryption source, browser encryption source

Pairing uses a random 32-byte invitation secret. The code puts that secret in a URL fragment and computes its SHA-256 hash for the service. Invitation offers are AES-GCM encrypted; the handover mechanism uses X25519 and HKDF-derived keys to transfer content-key material. This provides a credible cryptographic pairing design, but does not independently prove the private service enforces one-time claims correctly. Pairing source

Network defaults are wss://relay.clawdline.com/v1/connect and https://api.clawdline.com. Cloud and remote-command permission default to false; direct connections default to enabled when Cloud is used. The documented WebRTC path carries the same encrypted envelopes for supported reads, with relay fallback. I inspected the relay integration, but did not fully audit the WebRTC implementation. Settings source, relay integration, wire specification

Important residual risks

1. A trusted endpoint can become a powerful attack endpoint

Clawdline accesses conversations, project files and terminals. An authorized operating browser can send instructions and use terminal functionality. Consequently, compromising that browser or machine could expose secrets or enable commands under your account—not merely leak chat history. Read-only pairing reduces effects, but still permits sensitive reads. Repository overview, grant boundaries

2. Encryption does not eliminate trust in the hosted web application

Browser keys are stored as non-extractable CryptoKeys in IndexedDB. My security inference: non-extractable does not stop malicious same-origin JavaScript from using those keys or reading decrypted content. A compromised hosted frontend or an XSS vulnerability could therefore undermine confidentiality despite sound encryption. I did not establish such a vulnerability, but the trust boundary remains. Browser key storage and decryption

3. Machine secrets are files, not hardware-protected keys

The daemon stores signing seeds and content keys as base64-encoded files, protected with 0700 directory and 0600 file permissions. This is not encryption at rest. Same-user malware, root access or exposed backups could obtain them. Key-store source

4. Cloud still learns metadata; Cloud-off is not necessarily offline

Routing identifiers, timestamps, message sizes and traffic patterns are outside payload encryption. The repository’s outbound inventory also lists update/build checks independently of Cloud, and STUN services for direct connectivity. That inventory explicitly describes an earlier revision, so I treat it as supporting documentation—not a complete verified egress inventory for this commit. Data-flow inventory

5. Revocation is not retroactive confidentiality

Revocation cannot erase plaintext or keys already copied by a device. The repository contains content-key rotation integration, but its accompanying record explicitly says acceptance remains pending. I cannot verify production future-content revocation guarantees from this review. Rotation implementation record

Installation protections and limitations

The installer contains a pinned Ed25519 release-verification key and verification machinery; its download helper enforces HTTPS except explicit loopback mirrors. Those protections reduce download-substitution risk, but still require trusting the installer, release signer and build pipeline. The release page claims a signed/notarized DMG; I did not independently validate that signature, notarization, manifest, or binary-to-source correspondence. Installer source, v2.1.3 release

Local HTTP code also includes authentication, same-origin checks, capability checks and pairing rate limits—positive safeguards, not proof every route is secure. HTTP gate, authorization source

Recommendation

Start local-only, without production secrets; enable Cloud only if needed, explicitly choose read-only pairing where possible, and pair only trusted browser profiles. Verify the exact release before installing.

Reading limitations: This was a targeted static review through public network access. Repository directory/API listings were partly inaccessible, although numerous commit-pinned raw files were readable. I did not read every source file, run tests, install binaries, capture traffic, or audit dependencies comprehensively. The private Cloud backend, deployed frontend, retention practices and production configuration were unavailable; the repository itself acknowledges that boundary. Accordingly, I found credible security mechanisms, not sufficient evidence for an unconditional “safe to install.” Public/private boundary

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