On Wed, 2016-04-13 at 11:00 +0100, Ben Hutchings 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 <b...@decadent.org.uk> 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 > package build process. But we can't put them in the linux source > package, because that results in a dependency loop.
So, given these requirements, what do you think now about supporting detached signatures? I spoke at greater length about what I'm trying to do at Linuxwochen Wien; see http://meetings-archive.debian.net/pub/debian-meetings/2016/mini-debconf-vienna/webm/Secure_Boot_vs_the_Debian_linux_package.webm#t=595 from about 9'55" to 17'30". Ben. > > > > > > > > > > > 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. > > [...] > > > > > > > > + /* Try to open a detached signature. If it's missing, that's OK. > > > */ > > > + if (asprintf(&sig_filename, "%s.sig", filename) < 0) { > > > + err = -errno; > > > + goto error; > > > + } > > > + file->sig_fd = open(sig_filename, O_RDONLY|O_CLOEXEC); > > > + if (file->sig_fd < 0 && errno != ENOENT) { > > > + err = -errno; > > > + goto error; > > > + } > > This can't really work if the module is being loaded uncompressed (I > > think nowadays we can even add support for compressed modules... > > Rusty, any input here?). > > > > When the module is being directly loaded, the direct flag gets set so > > kmod_module_insert_module() knows it can try to use finit_module(). > > Since you have an external signature what would happen is that we > > would load the signature, but try to load the module in the kernel > > without it. > It does work. I changed load_reg() to disable direct loading.when > there's a detached signature. > > Ben. > > > > > I'm still not convinced the split module + signature is actually a good > > thing. > > > > > > Lucas De Marchi -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway.
signature.asc
Description: This is a digitally signed message part
