A proposal to let the Linux kernel verify module integrity using plain hashes — rather than only signatures — has reached its fifth revision, with its author outlining the problem at the 2026 Linux Plumbers Conference (LPC) as distributions press for stronger supply-chain guarantees that do not conflict with reproducible builds.
According to LWN.net, the patch set from Thomas Weißschuh was posted in v5 form on the public kernel mailing list in May 2026, continuing a discussion that first surfaced in earnest roughly a year and a half ago. At LPC 2026, Weißschuh described the core problem: distributions want kernel-module integrity guarantees, but they also want the build process to remain reproducible — and the two goals do not always sit comfortably together.
That tension is the proposal's most consequential angle, and it extends well beyond kernel modules. Cryptographic verification and reproducibility are not natural allies. Signature-based schemes generally require a private key to sign artifacts after they are built, and where that key lives — a build farm, a maintainer's workstation, a third-party service — varies from one pipeline to the next. Any such dependency introduces a variable that a from-scratch rebuild cannot reproduce. Hash-based verification sidesteps the problem: the expected digest can be embedded or distributed alongside the artifact, and any party can confirm integrity by recomputing it, with no key-handling step in the loop.
The kernel's existing module-signing mechanism embeds a PKCS#7 signature that the kernel validates against a set of trusted keys before loading a module. That approach is well established, and the hash-based design is explicitly intended as a complement to it, not a replacement. Distributions with mature signing workflows have little reason to migrate away from them. The proposal speaks instead to rebuild-focused distributions and downstreams wary of key sprawl — environments where the practical cost of signing infrastructure outweighs the incremental assurance it provides.
Design questions that review has focused on include how digests are computed, where they are stored, and how revocation or key-equivalent concerns would be handled in a hash-based scheme. The patch set has been revised multiple times, and LWN reports that no merge target has been set — a signal that the design remains in flux as it moves through review. Anyone tracking the thread on lore.kernel.org will have seen the iteration play out across several versions.
For DevOps and security teams, the practical relevance lies in attestation workflows: how an organization proves that the binaries it deploys are the binaries it intended to build. Teams operating in regulated or audit-heavy environments — including infrastructure groups in Hong Kong and elsewhere that must reconcile vendor assurance requirements with reproducible-build commitments — will recognise the same trade-off. The proposal itself carries no Hong Kong-specific dimension; the relevance is to the shared engineering problem it describes. Hash-based checks offer a way to demonstrate integrity without threading a secret-key operation through every stage of the pipeline.
The proposal matters to the wider open-source community because it reframes a recurring infrastructure argument. Signing is the default answer to supply-chain integrity questions, but it is not the only one, and for a class of builders the signature step is precisely what makes verification awkward. Whether v5 survives review unchanged remains to be seen; with no merge window targeted yet, the discussion on the kernel mailing list remains the place to watch.
一項讓 Linux 核心（kernel）以單純雜湊值（而非僅靠簽章）驗證模組完整性的提案已進入第五版修訂，提案作者並在 2026 年 Linux Plumbers Conference（LPC）上闡述相關問題。各發行版正敦促加強供應鏈保障，同時要求不致與可重現建置（reproducible builds）產生衝突。
據 LWN.net 報導，Thomas Weißschuh 的 patch set 於 2026 年 5 月以 v5 形式發布於公開的 kernel mailing list，延續約一年半前正式展開的討論。Weißschuh 在 LPC 2026 上指出核心問題：發行版既希望獲得 kernel module 的完整性保障，也希望建置流程維持可重現，而這兩個目標未必總能相容。
這項張力是提案中影響最深遠的一環，而且遠不止於 kernel module。密碼學驗證與可重現性並非天然盟友。基於簽章的方案通常需要私鑰在產物建置後加以簽署，而該私鑰存放的地點——建置農場（build farm）、維護者的工作站、第三方服務——因 pipeline 而異。此類依賴會引入任何從零重建都無法重現的變數。基於雜湊值的驗證則繞過了這個問題：預期的 digest 可以嵌入產物或隨產物一同分發，任何一方只需重新計算即可確認完整性，過程無需處理任何密鑰。
核心現有的模組簽章機制會嵌入 PKCS#7 簽章，由核心在載入模組前對照一組受信任的密鑰加以驗證。該方式已行之有年，而基於雜湊值的設計明確定位為其補充，而非取代。擁有成熟簽章工作流程的發行版沒有理由遷離現有做法。提案針對的其實是側重重建的發行版，以及對密鑰氾濫（key sprawl）有所顧慮的下游項目——在這些環境中，簽章基礎設施的實際成本已超出其所提供的額外保證。
審閱過程聚焦的設計問題包括：digest 如何計算、儲存於何處，以及雜湊值方案如何處理撤銷（revocation）或密鑰等效問題。該 patch set 已多次修訂，LWN 報導指目前尚未設定 merge target——這意味著設計在審閱過程中仍存在變數。追蹤 lore.kernel.org 上該討論串的人士，應已見證其歷經多個版本的反覆迭代。
對 DevOps 及安全團隊而言，實際關聯在於 attestation 工作流程：組織如何證明其部署的二進位檔案正是原本預期建置的產物。在受監管或審計繁重的環境中運作的團隊——包括香港及其他地區須同時滿足供應商保證要求與可重現建置承諾的基礎架構團隊——都會認同同一項取捨。該提案本身並無香港特定層面；相關之處在於它所描述的共通工程問題。基於雜湊值的校驗提供了一種展示完整性的方式，無需在 pipeline 每個階段嵌入 secret key 操作。
這項提案對整個 open source 社群意義重大，因為它重新框定了一場反覆出現的基礎設施之爭。簽章是供應鏈完整性問題的預設答案，但並非唯一答案；對某類建置者而言，簽章步驟恰恰是令驗證變得棘手的原因。v5 能否原封不動通過審閱仍有待觀察；在尚未設定 merge window 的情況下，kernel mailing list 上的討論仍是最值得關注的所在。