1. 核心論點：開源的幻覺與信任斷層
在軟體工程中，「開源（Open Source）」的核心價值在於「可審計性（Auditability）」與「可重現性（Reproducibility）」。理想狀態下，使用者下載的執行檔（Binary）應由公開的原始碼（Source Code），經由透明、不可篡改的自動化流程（CI/CD）編譯而成。
然而，針對 Cherry Studio 與 Chatbox 的深度審計揭示了一個殘酷的現實：雖然看得到原始碼，但你下載的執行檔卻未必來自那裡。 兩者皆存在嚴重的「信任斷層」：
- Cherry Studio：陷入「混合建置」泥沼。因代碼簽章技術限制與混淆代碼的存在，其官方發布版本極高機率是由開發者在「個人電腦」上手動編譯並上傳的，而非純粹的 CI 產物 。
- Chatbox：採取「鏡像同步」策略。雖然有 CI 流程，但公開的程式碼僅是私有庫（Private Repo）的「快照」。你看到的是結果，而非過程，且分發管道（Cloudflare R2）脫離了 GitHub 的版本控制監控 。
2. 深度鑑識：Cherry Studio (CherryHQ)
狀態判讀：技術上的開源，實務上的黑箱
2.1 建置來源驗證：開發者環境的潛在污染
儘管 Cherry Studio 在 GitHub 上配置了 release.yml ，但證據顯示其 Windows 與 macOS 版本並非由 GitHub Actions 自動簽章並發布。
- 簽章斷層：CI 日誌顯示無法正確處理 macOS/Windows 的代碼簽章憑證 。為了讓軟體能通過作業系統的安全檢查（如 Gatekeeper），開發者被迫在本地環境手動編譯並簽章，再上傳覆蓋 Release 檔案 。
- 風險意涵：這意味著使用者信任的不是公開的程式碼，而是開發者的個人電腦是否乾淨。如果開發者的電腦感染了針對開發工具的惡意軟體（類似 XcodeGhost），惡意代碼將被直接編譯進官方簽章的程式中，而 GitHub 上的原始碼卻看起來完美無瑕 。
2.2 源碼純淨度：混淆代碼的入侵
更令人擔憂的是，源碼庫本身包含「不透明」組件。
- 內嵌混淆庫：在
src/main/integration/nutstore路徑下，發現了經過混淆（Obfuscated）的 JavaScript 代碼 。 - 審計死角：這段代碼是「黑盒子」，即便有自動化建置，CI 也只是機械地打包這段人類無法閱讀的代碼。這破壞了開源的定義——你無法驗證這段混淆代碼是否包含後門或過度的遙測（Telemetry）。
3. 深度鑑識：Chatbox (Chatbox AI)
狀態判讀：商業包裝下的「半透明」鏡像
3.1 建置來源驗證：被切斷的信任鏈
Chatbox 的公開儲存庫並非真正的開發戰場，而是一個「下游鏡像」。
Chatbox 的自動更新與下載並非直接來自 GitHub Releases，而是指向開發者控制的 Cloudflare R2 存儲桶 。
3.2 分發管道的隱憂：R2 存儲桶
- Sync from Pro：提交紀錄顯示 "copy files from pro repo"，證明真正的開發發生在不公開的私有庫中 。
- CI 的假象：雖然 Chatbox 使用 GitHub Actions 進行建置 ，但輸入源（Input Source）是私有庫的匯出檔案。使用者無法審查代碼的變更歷史，也無法確認匯出過程中是否隱藏了特定邏輯 。
- 中間人風險：開發者（或攻擊者若竊取憑證）可以隨時替換 R2 上的檔案，而不會在 GitHub 上留下任何痕跡 。這創造了一個單點故障，繞過了 GitHub 的公開版本紀錄。
3.3 隱私與遙測
Chatbox 作為商業軟體，內建了 Plausible, Google Analytics 等遙測工具 。其「雲端同步」功能雖方便，但未承諾零知識加密，意味著廠商有能力在伺服器端解密並存取用戶數據 。
4. 終極比對：誰的 Release 更可疑？
5. 結論與建議
結論
你下載的 release 確定是由 source code 的 repo 產生出來的嗎？
- 對於 Cherry Studio：
否定。 由於簽章技術限制與混淆代碼，其 Windows/macOS 版本極有可能是開發者手動編譯的。你信任的是開發者個人的資安防護，而非開源代碼。 - 對於 Chatbox：
形式上是，實質上無意義。它是自動建置的，但建置的原料來自一個你看不到的私有庫。你信任的是開發者「沒有在同步時夾帶私貨」的良心。
最後一道安全防線
如果您不得不使用，那麼請務必上傳至 VirusTotal 掃毒網站，確認至少安裝檔案是安全沒有病毒的，另外就是您提供給 App 的 API key 務必限制使用量，或是使用免費的 key 確保安全。
- 驗證雜湊值 (Hash Verification)：
若 GitHub Action 日誌中有輸出 SHA256，請務必與下載的檔案比對。若日誌中無雜湊值（常見於手動上傳），則該檔案的可信度應視為 Untrusted 。 - 隔離運行 (Sandboxing)：
鑑於兩者都無法達到 100% 的供應鏈透明度，請務必在 Windows Sandbox 或 虛擬機 (VM) 中運行這些應用程式。 - 網路防火牆策略：設定 Egress Filtering，僅允許程式連線至 LLM API (如
api.openai.com)，阻斷 Nutstore、Google Analytics 等遙測域名的連線 。 - 極致手段：自行編譯 (Build from Source)：
對於 Cherry Studio，若您有能力，建議 Clone 代碼後，手動刪除src/main/integration/nutstore混淆目錄，再自行編譯。這能確保您運行的版本是絕對純淨的 ，但是跟下載安裝版本可能會有落差。
