lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 4 Dec 2017 10:01:50 +0100
From:   Henning Schild <henning.schild@...mens.com>
To:     Ben Hutchings <ben@...adent.org.uk>
Cc:     <linux-kernel@...r.kernel.org>,
        Ben Hutchings <ben.hutchings@...ethink.co.uk>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Michal Marek <michal.lkml@...kovi.net>,
        <linux-kbuild@...r.kernel.org>,
        Konrad Schwarz <konrad.schwarz@...mens.com>
Subject: Re: [PATCH] builddeb: introduce variables for control-file
 customization

Am Fri, 1 Dec 2017 18:47:38 +0000
schrieb Ben Hutchings <ben@...adent.org.uk>:

> On Fri, 2017-12-01 at 19:34 +0100, Henning Schild wrote:
> > Am Fri, 1 Dec 2017 16:51:12 +0000
> > schrieb Ben Hutchings <ben@...adent.org.uk>:
> >   
> > > On Fri, 2017-12-01 at 15:56 +0000, Henning Schild wrote:  
> > > > The debian packages coming out of "make *deb-pkg" lack some
> > > > critical information in the control-files e.g. the "Depends:"
> > > > field. If one tries to install a fresh system with such a
> > > > "linux-image" debootstrap or multistrap might try to install
> > > > the kernel before its deps and the package hooks will fail.    
> > > 
> > > I assume you're talking about those hook scripts being run while
> > > the packages they belong to are only unpacked?  I hadn't thought
> > > about this issue, but it seems to me that those hook scripts
> > > generally ought to be fixed to handle this case properly.  Most
> > > of the packages installing hook scripts for kernel packages are
> > > not going to be dependencies of linux-image packages, so it will
> > > never be safe for them to assume their package has been fully
> > > installed.  
> > 
> > Yes these hook scripts fail when installing the kernel on another
> > system. Indeed we seem to have a case where packages installed on
> > the build-machine cause install-time deps for the package.  
> 
> Can you give an example?  I don't see how that would happen.

Scripts in /etc/kernel/ will end up as hooks for the kernel-package, if
you do not set KDEB_HOOKDIR. Looking at an example system that pulls in
things like "pm-utils, grub-pc .. initramfs". With this mechanism any
package placing a hook in /etc/kernel can influence the deps. I guess
in practice that is prevented with policies on what these scripts are
allowed to do.

> > In my case the build-machine is pretty minimal but i still want
> > some of that i.e. initramfs.
> >   
> > > > Different debian-based distros use different values for the
> > > > missing fields. And the values differ between distro versions
> > > > as well. So hardcoding of e.g. "Depends" is not possible.    
> > > 
> > > The dependencies also depend on the kernel configuration.  (And a
> > > custom kernel built with 'make deb-pkg' often won't have any
> > > dependencies outside of essential packages.)  
> > 
> > In fact it does not have any at the moment, there is no essential.
> > Or maybe that is hidden in debian-magic.  
> [...]
> 
> Essential packages are always installed, which means there is no need
> to declare a dependency on them (in fact it is discouraged):
> https://www.debian.org/doc/debian-policy/#dependencies

Ok, i will need to double-check how multistrap deals with those.

Henning

> Ben.
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ