Re: Build failed in Jenkins: dpkg-binaries » i386 #228

[Michael Prokop]

Hi!

* Guillem Jover [Sun Aug 10, 2014 at 09:17:02AM +0200]:
> On Sun, 2014-08-10 at 08:49:52 +0200, Jenkins Team at Grml wrote:
> > See 

> > I: Building the package
> > W: no hooks of type A found -- ignoring
> > I: Running cd tmp/buildd/*/ && env PATH="/usr/sbin:/usr/bin:/sbin:/bin" 
> > dpkg-buildpackage -us -uc  -B -B -rfakeroot
> > dpkg-buildpackage: cannot combine -B and -B

> > Use --help for program usage information.
> > E: Failed autobuilding of package
> > I: user script /srv/pbuilder/build/cow.28879/tmp/hooks/C10shell starting

> I'm pondering about fixing this in dpkg to at least allow the same option
> to be specified multiple times for backward compat, but I'm wondering why
> is the script passing it twice? Could that be fixed there?

The -B option is set in this jenkins-debian-glue run for:

1) Host architecture [amd64] does not match build architecture [i386]
2) The package provides arch 'all' + 'any', so we're enabling the -B
   buildoption for the i386 arch build (since the main build is the
   one for amd64)

That's also why the amd64 build works fine (no -B option) but just
the i386 one (-B -B) fails. I could of course unify the options used
in the final jenkins-debian-glue cmdline, but a backward compat fix
would be very much appreciated as I noticed that other users
(outside of jenkins-debian-glue) ran into this very same issue.

Thanks, Guillem!

regards,
-mika-


signature.asc
Description: Digital signature

[PATCH] dpkg-buildflags: Remove stackprotectorstrong arch blacklist

[Romain Francoise]

As of gcc-defaults 1.130 all architectures have moved to GCC 4.9, so we
can remove the architecture blacklist for stackprotectorstrong.

diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm
index 5223e0e..f9e8a84 100644
--- a/scripts/Dpkg/Vendor/Debian.pm
+++ b/scripts/Dpkg/Vendor/Debian.pm
@@ -137,12 +137,6 @@ sub add_hardening_flags {
#   compiler supports it incorrectly (leads to SEGV)
$use_feature{stackprotector} = 0;
 }
-if ($arch =~ /^(?:m68k|or1k|powerpcspe|sh4|x32)$/) {
-   # "Strong" stack protector disabled on m68k, or1k, powerpcspe, sh4, x32.
-   #   It requires GCC 4.9 and these archs are still using 4.8 as of
-   #   gcc-defaults 1.128.
-   $use_feature{stackprotectorstrong} = 0;
-}
 if ($cpu =~ /^(?:ia64|hppa|avr32)$/) {
# relro not implemented on ia64, hppa, avr32.
$use_feature{relro} = 0;


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/871tsnmodp@kima.orebokech.com

Re: [PATCH] dpkg-buildflags: Remove stackprotectorstrong arch blacklist

[Guillem Jover]

Hi!

On Mon, 2014-08-11 at 10:17:22 +0200, Romain Francoise wrote:
> As of gcc-defaults 1.130 all architectures have moved to GCC 4.9, so we
> can remove the architecture blacklist for stackprotectorstrong.
> 
> diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm
> index 5223e0e..f9e8a84 100644
> --- a/scripts/Dpkg/Vendor/Debian.pm
> +++ b/scripts/Dpkg/Vendor/Debian.pm
> @@ -137,12 +137,6 @@ sub add_hardening_flags {
>   #   compiler supports it incorrectly (leads to SEGV)
>   $use_feature{stackprotector} = 0;
>  }
> -if ($arch =~ /^(?:m68k|or1k|powerpcspe|sh4|x32)$/) {
> - # "Strong" stack protector disabled on m68k, or1k, powerpcspe, sh4, x32.
> - #   It requires GCC 4.9 and these archs are still using 4.8 as of
> - #   gcc-defaults 1.128.
> - $use_feature{stackprotectorstrong} = 0;
> -}
>  if ($cpu =~ /^(?:ia64|hppa|avr32)$/) {
>   # relro not implemented on ia64, hppa, avr32.
>   $use_feature{relro} = 0;

Thanks! Merged locally will be included in 1.17.12.

Regards,
Guillem


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140811090741.ga24...@gaara.hadrons.org

Re: [RFC PATCH 0/3] Including file signatures in .deb packages]

[Guillem Jover]

Hi!

I think perhaps you might have meant to send this to the debhelper
maintainers? Otherwise here's some comments.

On Fri, 2014-08-08 at 12:57:38 -0400, Mimi Zohar wrote:
> We're looking to include file signatures in the different package
> formats (eg.rpm, deb) and install them as 'security.ima' extended
> attributes(xattrs).  These signatures could then be used to enforce
> local file integrity and included in the IMA measurement list to
> provide file provenance.

I've pending to go back to the discussion about adding signatures to
the .deb files (bug #340306), hopefully before the freeze. Those
signatures should probably be stored (if at all) in the dpkg database,
as there's no guarantee the filesystem would support xattr, and this
will be done automatically as long as this stuff is shipped in a
file in the .deb control area. Also if an attacker could modify the
file they might as well be able to modify the xattrs, so I'm not sure
this adds any security. Integrity sure, but we've got md5sums already
which should be fine for that, and the «dpkg --verify» command now.

> The existing md5sums file contains the file hash and name for each file
> included in the package.  This makes it the most logical place for
> storing the file signatures, other than the hash being md5.  For now,
> this patch set assumes the existence of an equivalent sha256sums file.
> (For convenience, I've duplicated the dh_md5sums helper naming it
> dh_sha256sums.)

If such a new command is desirable, I'd go instead for something like
dh_checksums or similar so that it does not need to change every time
a different algo is added or switched to.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140811131352.gc29...@gaara.hadrons.org

Re: [RFC PATCH 0/3] Including file signatures in .deb packages]

[Mimi Zohar]

On Mon, 2014-08-11 at 15:13 +0200, Guillem Jover wrote: 
> Hi!
> 
> I think perhaps you might have meant to send this to the debhelper
> maintainers? Otherwise here's some comments.

Thank you for the feedback!  The patches went through a number of
iterations.  The initial one modified dpkg directly.  Does it make sense
to copy both mailing lists on this discussion of adding signatures
to .deb packages?

> On Fri, 2014-08-08 at 12:57:38 -0400, Mimi Zohar wrote:
> > We're looking to include file signatures in the different package
> > formats (eg.rpm, deb) and install them as 'security.ima' extended
> > attributes(xattrs).  These signatures could then be used to enforce
> > local file integrity and included in the IMA measurement list to
> > provide file provenance.
> 
> I've pending to go back to the discussion about adding signatures to
> the .deb files (bug #340306), hopefully before the freeze. 

Thank you for the reference to the previous discussions.

> Those
> signatures should probably be stored (if at all) in the dpkg database,
> as there's no guarantee the filesystem would support xattr, and this
> will be done automatically as long as this stuff is shipped in a
> file in the .deb control area. Also if an attacker could modify the
> file they might as well be able to modify the xattrs, so I'm not sure
> this adds any security. Integrity sure, but we've got md5sums already
> which should be fine for that, and the «dpkg --verify» command now.

In this design are signatures verified before the file is read/executed
or is it a separate, out of band process that is run independently?  It
sounds like the latter.

IMA-appraisal, based on policy, enforces local file integrity.  Once
3.17 is released, certificates, containing a key used to verify file
signatures, will need to be signed by a system trusted key (UEFI/shim db
or builtin), before being added to the IMA keyring.  This extends the
UEFI signature chain of trust, which is rooted in HW, to the OS.

> > The existing md5sums file contains the file hash and name for each file
> > included in the package.  This makes it the most logical place for
> > storing the file signatures, other than the hash being md5.  For now,
> > this patch set assumes the existence of an equivalent sha256sums file.
> > (For convenience, I've duplicated the dh_md5sums helper naming it
> > dh_sha256sums.)
> 
> If such a new command is desirable, I'd go instead for something like
> dh_checksums or similar so that it does not need to change every time
> a different algo is added or switched to.

Agreed.

thanks,

Mimi


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1407766831.6470.93.ca...@dhcp-9-2-203-236.watson.ibm.com