圖說：墨寒讓 v2.1.0-rc.1 通過檔案指紋、成分、來源與安全下載的檢查

圖說：墨寒的 GitHub 開源專案主視覺

昨天把 ZIP、EXE 與 MSI 三種發行方式分清楚，今天要問一個下載者更難從畫面判斷的問題：GitHub Release 上有一個檔案，怎麼知道它真的是這個版本、下載過程沒有改變，而且裡面包含哪些元件？

早期獨立開發常見做法，是上傳一個 ZIP、在文章貼連結，然後宣布發布完成。對只有幾個朋友測試的作品或許勉強可行；墨寒既然公開給陌生人下載，又能保存記憶與連接工具，我不能只靠「相信作者」四個字。

v2.1.0-rc.1 的發行流程因此不只產生安裝包，也產生一組讓檔案可以被核對的證據。

SHA256 像檔案的指紋

每個發行檔都計算 SHA256。使用者下載後重新計算，若與 Release 列出的值一致，可以確認位元內容沒有在傳輸或儲存中改變。

這不表示檔案本身必然沒有所有漏洞；雜湊回答的是「你拿到的是否就是發布者列出的那一份」，不是「程式永遠安全」。而且雜湊必須來自可信的官方 Release，若檔案與假雜湊一起放在惡意網站，核對仍沒有意義。

v2.1.0-rc.1 也提供完整校驗清單，讓 ZIP、EXE、MSI、MST 與其他發行產物都有對應值，不只挑一個主要下載檔。

SBOM 是成分表，不是安全保證書

軟體會包含 Python 套件與封裝元件。CycloneDX SBOM 可以列出軟體材料，讓維護者與安全工具日後查詢某個相依套件是否受到已知問題影響。

我把它理解成食品成分表：看得見用了什麼，比只看包裝名稱更容易追蹤；但有成分表不代表每一項都永遠沒有風險，也不會自動修正漏洞。它必須和相依套件審查、CodeQL、更新與人工判斷一起使用。

對開源專案而言，SBOM 也讓企業或工程師在下載前有更標準的資料可檢查，不必猜封裝裡到底帶了什麼。

Artifact Attestation 回答「它從哪個流程來」

Artifact Attestation 把發行檔與 GitHub Actions 建置流程連結，提供可驗證的來源聲明。它能幫助確認產物由指定儲存庫與工作流程建立，不是某人手動在不明電腦壓縮後冒充官方版本。

這仍不是魔法護盾。若來源程式本身有問題，正式流程也會忠實建出有問題的檔案；所以 PR 審查、受保護 main、CI 與祕密掃描仍不可少。

供應鏈安全不是找一個徽章替代其他檢查，而是把「誰改了什麼、在哪裡測、由哪條流程建置、使用者拿到哪一份」串起來。

更新清單不能相信任何下載網址

墨寒內建穩定版與預覽版更新檢查，但它不會看到一個網址就下載執行。更新資訊只能來自官方 GitHub HTTPS 來源，並驗證儲存庫、標籤、版本格式、檔名、宣告大小與 SHA256。

就算全部符合，程式也只向使用者提出更新，仍需明確確認才會啟動安裝。更新不能默默覆蓋，也不能把現有個人設定當成程式檔一起刪掉。

這些條件也防止錯誤設定把測試檔、別的儲存庫或尺寸異常內容當成正式更新。模型本身沒有權限改寫更新來源。

發布流程也要保護官網

GitHub Release 是下載權威來源，WordPress 官網只顯示版本、按鈕與校驗資訊，不保存安裝檔。若維護者設定專用 Application Password，發行工作可以只更新頁面中由標記管理的墨寒下載區塊。

「只更新標記區塊」很重要。官網還有我手工設計的作品敘事與視覺，不能為了換一個版本號就整頁覆蓋。自動化帳號權限也應縮小，密碼放在 GitHub Secrets，不出現在工作流程輸出。

如果自動同步失敗，GitHub Release 仍是正式來源；網站可以稍後修正，不應反過來讓發布流程修改未知頁面。

版本頻道要讓「想嘗鮮」成為明確選擇

穩定版與預覽版使用者承受風險的意願不同。更新清單需要標明版本、頻道與發布狀態，不能只比較一串看起來比較大的數字。RC 使用者可以選擇接收預覽更新，偏好穩定的人則不該被測試版主動打擾。

版本比較也要防止降級與錯誤標籤。若本機版本比清單更新、來源儲存庫不符或檔名屬於另一種架構，就不應提供安裝。Release 被撤回時，程式也不能繼續依賴舊快取宣稱它是最新安全版本。

版本說明則要把使用者看得見的變化、修正、已知限制與驗證狀態寫清楚。它不是把 commit 標題全部貼上，而是讓下載者判斷是否現在更新、更新後要注意什麼。

一次 v2.1.0-rc.1 發布真正通過哪些門

版本標籤觸發後，流程先做公開內容稽核與完整測試，再建置 Windows x64 ZIP、EXE 與 MSI；封裝完成後跑自我檢查、事件迴圈冒煙、靜默安裝與解除安裝，接著產生校驗清單、SBOM、更新資訊、Attestation 與版本說明。

我仍要看 GitHub 工作是否全部綠燈、是否有安全警告或未處理 PR 對話。這次 v2.1.0-rc.1 的 Release 工作完成了 Python 3.14 建置、55 項完整測試、公開內容稽核、封裝自測、EXE／MSI／MST 驗證、Gitleaks、校驗清單、SBOM、更新資訊與 Attestation，最後才發布預發行版。流程成功不代表未來不會發現 Bug，因此版本仍標示 RC；但至少「這一份 v2.1.0-rc.1 從哪裡來、測過什麼、如何核對」不再只存在作者口頭保證。

發行的可信度不是下載次數，而是每個人都能用相同證據驗證。

明天 Day 27，我們把鏡頭從公開發行檔轉回私人電腦。金鑰、長期記憶、對話、備份與日誌應該各自住在哪裡？為什麼「都存在本機」仍不等於放在同一個資料庫？

SHA256、SBOM 與 Attestation 各自證明不同面向，不能替代程式審查、漏洞更新與使用者確認。