On Tue, May 6, 2025, at 15:24, James Bottomley wrote:

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

I'm not sure the 'hermetic build' parallel is so applicable here: typically a
hermetic build will produce an artifact and a signature, and when you embed
that result in a larger aggregate, you only embed the artifact (not the
signature) and sign the aggregate. With module signatures, the module *and*
their signatures are embedded in the aggregate (e.g. ISO, disk image), which is
where (at least in my case) the friction comes from.

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.

Right: there is no friction validating the module signatures, that is fine.
There is friction validating the aggregate artifact (e.g. ISO, disk image),
though, because of those signatures embedded into it.

As you mentioned earlier, of course this is *possible* to do (for example by
adding the signatures as inputs to the second 'independent' build or by
creating a hard-to-validate 'check recipe' running the build in reverse).
Still, checking modules at run time by hash instead of by signature would be a
much simpler option for such scenario's.

quoted

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

That is interesting history, thanks for digging that up. Of the 2 problems Ben
mentions running into there, '1' does not seem universal (I think this feature
is indeed mainly interesting for systems where you don't _want_ anyone to be
able to load locally-built modules), and '2' is a problem that detached
signatures have but module hashes don't have.

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.

I haven't experienced that issue with the module hashes yet.

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

Cool, I was aware of that page but didn't know it was initially contributed by
Debian.

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).

At least I don't really come to this from the packaging perspective, but from
the "building an independently verifiable ISO/disk image" perspective.
Separating the modules and the signatures into separate packages doesn't help
me there, since they'd still both need to be present on the image.


Kind regards,

-- 
Arnout Engelen
Engelen Open Source
https://engelen.eu