桌面應用程式的下載信任：校驗碼、簽章與建置來源各自證明什麼

假設同一個桌面應用程式在發行頁和一個鏡像網站上都提供下載。檔案名稱相同，版本號也相同，使用者卻仍然需要回答：它們是不是同一份檔案？由誰發佈？是否來自預期的程式碼和建置過程？適不適合在自己的裝置上運行？

這些問題需要不同的證據。把所有驗證方式統稱為“安全認證”，容易讓使用者期待它們實際無法保證的事情，也會讓開發者忽略發行流程中的空白。

校驗碼回答檔案是否一致

下載後計算雜湊，並與預期值比較，可以檢查檔案內容是否一致。但這裡有一個重要前提：預期值本身來自可信渠道。如果檔案與校驗值都來自同一個未經確認的頁面，兩者一致仍不足以證明發佈者身分。

反過來，雜湊不同意味著檔案存在差異，卻不能僅憑這一點斷定惡意。不同建置、重新打包或錯誤下載都可能造成變化。正確做法是暫停把它當作已驗證版本，重新確認檔案來源、目標平台和對應的校驗記錄。

對發行方而言，清晰的檔案命名、版本資訊和校驗清單，應當一起維護。不要讓使用者從舊文章複製一串雜湊，再拿它比較另一個平台或另一次建置的安裝套件。

簽章需要驗證“預期是誰”

數位簽章把簽署者與被簽資料關聯起來，但驗證程式還需要判斷這個身分是否符合預期。Sigstore 的驗證文件要求核對簽章以及相關身分、簽發者等條件，體現的就是這種區分。Sigstore 驗證文件

因此，使用者看到“簽章有效”時，還應確認它對應哪個發佈者或工作流程；開發者則應明確允許哪些身分簽署正式發行物。任何能通過某種數學驗證的簽章，都不應自動獲得產品正式版本的地位。

發行方更換憑證或簽章方式時，也需要提供可核對的說明。讓使用者臨時信任一個來歷不明的憑證，並不是一個完整的更新流程。

建置來源把安裝套件連接到生產過程

GitHub 的 artifact attestation 可以記錄建置來源，幫助驗證產物與倉庫、工作流程等資訊的關聯。它為核對“這份檔案怎樣產生”提供了證據，但驗證時仍需檢查實際產物及預期身分。GitHub 建置證明文件

SLSA 的建置等級進一步區分來源記錄的存在、託管平台生成的簽章來源記錄，以及更嚴格的建置平台防護要求。引用等級時，應說明適用範圍與依據，不能把等級數字當作覆蓋所有軟體風險的評分。SLSA 建置等級

這些證據可以相互補充。開發者應讓使用者知道已經提供了哪些證據，以及哪些檢查還需要獨立完成。

可重現建置需要明確輸入與環境

Reproducible Builds 項目把可重現建置定義為：給定相同原始碼、建置環境和建置說明，能夠得到逐位元組一致的指定產物。它比“在我的電腦上能編譯”提出了更明確的驗證目標。可重現建置定義

我們建議發行方保留工具鏈、依賴鎖定資訊、建置參數與產物對應關係。若尚未達到可重現，也應準確記錄目前能夠重建到哪一步，而不是省略差異後宣佈通過。

公開倉庫的範圍也要講清楚。倉庫可能包含核心原始碼，也可能主要包含建置工具、配置和上游生成的應用套件。使用者需要知道自己實際能檢查和重新建置哪些部分，才能合理評價來源證據。

使用者可以採用的下載檢查順序

1. 從項目的正式入口確認發行倉庫，避免僅依賴搜尋廣告或轉發連結。
2. 閱讀版本說明，確認作業系統、處理器架構和發行通道。
3. 核對檔案與對應校驗值；有簽章或來源證明時，再驗證預期身分及適用範圍。
4. 檢查維護狀態和已知限制，避免把“最新標籤”直接理解為適合生產使用。
5. 遇到資訊不一致時，保留版本與檔案名，通過項目支持渠道核實。

這套流程不要求每位使用者都成為建置工程師。產品可以把複雜證據整理成清楚的發行頁面：檔案從哪裡來、適合誰、怎樣檢查、出現異常去哪裡詢問。

對開發者來說，長期維護這條資訊鏈比一次性貼出“已驗證”的標籤更有價值。舊版本撤回、簽章更換和更新失敗時，使用者仍應找得到對應說明。

AlphaBiz 的公開倉庫說明區分了建置工具與上游生成的應用套件。討論此類桌面應用程式時，我們也應按真實範圍解釋可檢查的內容，而不把公開倉庫、完整原始碼和可重現發行混為一談。AlphaBiz 項目說明

開發者可以從補齊一份發行證據清單開始；使用者則可以先檢查自己最常用應用的一個下載檔案。歡迎在 AlphaBiz Discussions 交流你希望發行頁提供哪些驗證資訊。