On Sat, 2025-05-03 at 10:19 +0200, Arnout Engelen wrote:

On Fri, May 2, 2025, at 15:30, James Bottomley wrote:

quoted

On Fri, 2025-05-02 at 08:53 +0200, Thomas Weißschuh wrote:

quoted

Specifically the output of any party can recreate bit-by-bit
identical copies of all specified artifacta previous build (the
public key, module signatures) is not available during the
rebuild or verification.

You just strip the signatures before verifying reproducibility.

If the goal is: "verify the Linux Kernel is reproducible", that could
work. It gets increasingly cumbersome when you're trying to check the
reproducibility of some larger artifact that embeds the Linux kernel
(and lots of other stuff), like an ISO or disk image, though: you'd
have to unpack/mount it, check all its contents individually (perhaps
recursively), and strip signatures in 'just the right places'.

Most GPL/LGPL software requires a build recipe anyway.  Realistically,
you're just proving you can exercise that in reverse.

Writing such tooling is a chore, but of course feasible: diffoscope
already comes a long way (though checking large images may take some
resources). The problem is trusting such tooling: instead of 'simply'
checking the images are identical, suddenly I now have to convince
myself there's no shenanigans possible in the disk image
interpretation and other check tooling, which gets nontrivial fast.

I'll repeat the key point again: all modern hermetic build systems come
with provenance which is usually a signature.  Developing the tooling
is already a requirement.

Plus, you've got to remember that a signature is a cryptographic
function of the hash over the build minus the signature.  You can't
verify a signature unless you know how to get the build minus the
signature.  So the process is required to be deterministic.

quoted

All current secure build processes (hermetic builds, SLSA and the
like) are requiring output provenance (i.e. signed artifacts).  If
you try to stand like Canute against this tide saying "no signed
builds", you're simply opposing progress for the sake of it

I don't think anyone is saying 'no signed builds', but we'd enjoy
being able to keep the signatures as detached metadata instead of
having to embed them into the 'actual' artifacts.

We had this debate about 15 years ago when Debian first started
reproducible builds for the kernel.  Their initial approach was
detached module signatures.  This was the original patch set:

https://lore.kernel.org/linux-modules/20160405001611.GJ21187@decadent.org.uk/ (local)

And this is the reason why Debian abandoned it:

https://lists.debian.org/debian-kernel/2016/05/msg00384.html

The specific problem is why detached signatures are almost always a
problem: after a period of time, particularly if the process for
creating updated artifacts gets repeated often matching the output to
the right signature becomes increasingly error prone.

Debian was, however, kind enough to attach what they currently do to
get reproducible builds to the kernel documentation:

https://docs.kernel.org/kbuild/reproducible-builds.html

Although they went for deterministic signing, I will note that it is
perfectly possible to follow their receipe with an ephemeral
certificate as well.

However, if you want to detach the module signatures for packaging, so
the modules can go in a reproducible section and the signatures
elsewhere, then I think we could accommodate that (the output of the
build is actually unsigned modules, they just get signed on install).

Regards,

James