On 5/2/25 3:30 PM, James Bottomley wrote:
Under a your interpretation of the above, any signed binary isn't
"reproducible" even if the underlying build was, which means any secure
boot kernel would never be reproducible because it also has to be a
signed binary. The solution is simple: can you strip the signature and
reproduce the build? If yes, then the build is reproducible and even
fits with the "any party can recreate ..." above. This is the
interpretation pretty much everyone else has been using. It's why
people like Intel with source only availability and Intel build only
signing tout reproduceability: they only issue signed confidential VM
firmware, but you can technically reproduce the build of the firmware
minus the signature but you can never sign it.
The secure-boot signature is easier to deal with, I also think there'd
be one package that contains just the unsigned kernel+modules (with the
modules being pinned by a cryptographic hashset), and a second one that
takes the kernel secure-boot signature as a source-code input, that is
calculated after the first package was successfully built.
Arch Linux has also considered patching the module-signing-script into
some kind of oracle that doesn't use any private key and instead selects
the right pre-computed signature for the given content, but:
- that would be terribly annoying to maintain/operate
- any reproducible builds regression would make the build fail, because
the kernel wouldn't be bootable
You just strip the signatures before verifying reproducibility.
[...]
If you take off the appended signature off the module, you can verify
reproduceability.
[...]
So you think stripping signatures is failure prone? If that were the
case then so would be verifying signatures upon which our whole secure
boot and signed module loading is based.
[...]
Or you simply ship tools to remove the signature;
sbattach --remove <signed efi variable>
already does this for you ...
It reads like you assume somebody sits down and explicitly looks at the
linux package manually, but the reproducible builds tooling considers
the package content to be fully opaque and doesn't have any
special-casing of any package:
https://github.com/archlinux/archlinux-repro
https://salsa.debian.org/debian/devscripts/-/blob/main/scripts/debrebuild.pl?ref_type=heads
I'd rather not deal with the consequences of weakening the comparison
and possibly introducing exploitable loop-holes in any of the layers we
wouldn't be able to bit-for-bit compare anymore (like e.g. tar).
It would also break the concept of `f(source) -> binary`, "you can
deterministically derive the binary packages from the documented build
inputs", and instead you'd always need to fuzzy-match against what
somebody else built.
cheers,
kpcyrd
