On Sat, 2016-05-21 at 15:31 -0300, Lucas De Marchi wrote:

On Wed, Apr 13, 2016 at 7:00 AM, Ben Hutchings [off-list ref] wrote:

quoted

On Wed, 2016-04-13 at 01:05 -0300, Lucas De Marchi wrote:

quoted

Hi,

CC'ing Rusty

On Mon, Apr 4, 2016 at 9:32 PM, Ben Hutchings  wrote:

quoted

Debian will not sign modules during the kernel package build, as this
conflicts with the goal of reproducible builds.  Instead, we will
generate detached signatures offline and include them in a second
package.

Is this a decision already? It doesn't look as a good reason - you
would already need to provide a signing key (CONFIG_MODULE_SIG_KEY)
anyway for this to work. How is leaving the module signature in
another package be any better than just signing the module?  If you
have the signature, the build is just as reproducible as before.

I think we may have different ideas about what reproducibility means.
When I say reproducible I mean *anyone* with the right tools installed
can reproduce the binary packages (.deb) from the source package (.dsc
and tarballs).

The signing key obviously isn't available to everyone, so the source
package has to include detached signatures prepared outside of the

And how is this signature prepared?  Since it needs the compiled
module it would be a matter of changing the compiler, even minor
version, to invalidate the argument of reproducible build. It seems
very fragile to me.

The versions of build tools have to be recorded:
https://reproducible-builds.org/docs/formal-definition/
https://wiki.debian.org/ReproducibleBuilds/BuildinfoSpecification

quoted

package build process.  But we can't put them in the linux source
package, because that results in a dependency loop.

quoted

quoted

We could attach the signatures when building this second package or at
installation time, but that leads to duplication of all modules,
either in the archive or on users' systems.

To avoid this, add support to libkmod for concatenating modules with
detached signatures (files with the '.sig' extension) at load time.

this has the drawback that finit_module() can't be used.

So does module compression, but it's still a supported option.

This is easily fixed by teaching the kernel to handle the fd as a
compressed file.

This sounds speculative.

The kernel already has the routines to uncompress
them anyway. Supporting detached signatures means it can't be fixed
anymore since we will have to use init_module() rather than
finit_module().

Why does that matter?  init_module() isn't deprecated.

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes instead of old ones.