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 <ben@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.