linux-kernel - Re: [PATCH v4 00/17] module: Introduce hash-based integrity checking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8b12f1d28d3859467c3b5f6bc352038ce7627e54.camel@HansenPartnership.com>
Date: Tue, 03 Feb 2026 08:18:09 +0000
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: David Howells <dhowells@...hat.com>, Mihai-Drosi Câju
	 <mcaju95@...il.com>
Cc: linux@...ssschuh.net, arnd@...db.de, arnout@...t.net,
 atomlin@...mlin.com,  bigeasy@...utronix.de, chleroy@...nel.org,
 christian@...sel.eu, corbet@....net,  coxu@...hat.com, da.gomez@...nel.org,
 da.gomez@...sung.com,  dmitry.kasatkin@...il.com, eric.snowberg@...cle.com,
 f.gruenbichler@...xmox.com,  jmorris@...ei.org, kpcyrd@...hlinux.org,
 linux-arch@...r.kernel.org,  linux-doc@...r.kernel.org,
 linux-integrity@...r.kernel.org,  linux-kbuild@...r.kernel.org,
 linux-kernel@...r.kernel.org,  linux-modules@...r.kernel.org,
 linux-security-module@...r.kernel.org,  linuxppc-dev@...ts.ozlabs.org,
 lkp@...el.com, maddy@...ux.ibm.com,  mattia@...reri.org, mcgrof@...nel.org,
 mpe@...erman.id.au, nathan@...nel.org,  naveen@...nel.org,
 nicolas.bouchinet@....cyber.gouv.fr, nicolas.schier@...ux.dev, 
 npiggin@...il.com, nsc@...nel.org, paul@...l-moore.com,
 petr.pavlu@...e.com,  roberto.sassu@...wei.com, samitolvanen@...gle.com,
 serge@...lyn.com,  xiujianfeng@...wei.com, zohar@...ux.ibm.com
Subject: Re: [PATCH v4 00/17] module: Introduce hash-based integrity checking

On Sun, 2026-02-01 at 17:09 +0000, David Howells wrote:
> Mihai-Drosi Câju <mcaju95@...il.com> wrote:
> 
> > > The current signature-based module integrity checking has some
> > > drawbacks
> > in combination with reproducible builds. Either the module signing
> > key is generated at build time, which makes the build
> > unreproducible, or a static signing key is used, which precludes
> > rebuilds by third parties and makes the whole build and packaging
> > process much more complicated.
> 
> There is another issue too: If you have a static private key that you
> use to sign modules (and probably other things), someone will likely
> give you a GPL request to get it.

The SFC just lost that exact point in the Vizio trial, so I think
you're wrong on this under US law at least.  There's no general ability
under GPLv2 to demand long lived signing keys.

Regards,

James