On Sat, 2016-05-21 at 15:31 -0300, Lucas De Marchi wrote: > On Wed, Apr 13, 2016 at 7:00 AM, Ben Hutchings <b...@decadent.org.uk> wrote: > > > > On Wed, 2016-04-13 at 01:05 -0300, Lucas De Marchi wrote: > > > > > > Hi, > > > > > > CC'ing Rusty > > > > > > On Mon, Apr 4, 2016 at 9:32 PM, Ben Hutchings wrote: > > > > > > > > > > > > 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 > > package build process. But we can't put them in the linux source > > package, because that results in a dependency loop. > > > > > > > > > > > > > > > > > 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.
signature.asc
Description: This is a digitally signed message part
