On 11/14/25 12:36 PM, Robin Candau wrote:
Hi everyone,
As discussed during this year's Arch summit, Thomas is seeking help /
support from projects that could benefit from his patch set which aims
to enable reproducible kernel packages for Linux distributions (see the
forwarded mail below).
As far as I can tell, this is something we would be interested in. I
think it would be nice if we could "officially" claim our interest as
"Arch Linux" to hopefully provide some assistance to Thomas for his
incoming discussion with upstream.
Does any of the kernel packages maintainers on our side wants to jump in
(or anyone else interested with some kernel knowledge, I guess)?
tl;dr: I'm very interested in this patch.
There's some prior discussion here (2024):
https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/merge_requests/1
It also has a note from anthraxx from January 2025. :)
The only "alternative" approach that has been discussed in Arch Linux
throughout the years (that I'm aware of), is "build the `linux` package
once with a regular PKGBUILD, generate signatures out of band and add
them to source=, edit the PKGBUILD to patch the signing script to use
the pre-computed signatures". This needs to be done for every update
(both pkgver= but likely also pkgrel=).
This would be very involved and if there's a reproducible builds
regression this would block further kernel updates or require us to
revert the workflow.
With the embedded hashing approach we wouldn't need to care about any of
this, and there's no special-casing required. Even if there are
reproducible builds regressions this wouldn't break/block the regular
update process and can be dealt with asynchronously.
Important for us would be:
- we would have both CONFIG_MODULE_HASHES and CONFIG_MODULE_SIG_KEY set
- CONFIG_MODULE_HASHES is used for in-tree modules
- CONFIG_MODULE_SIG_KEY is used for out-of-tree modules
- module authentication should use `HASH_MATCH || SIGNATURE_MATCH` and
not require both (otherwise we wouldn't be able to configure a
signing-key for out-of-tree modules without needing to sign our in-tree
modules, and we would be back to square one)
cheers,
kpcyrd
