+++ This bug was initially created as a clone of Bug #978949 +++

Description of problem:

  When a package with hardening-flags explicitly enabled in specs-file
  builds a lib using autotools and/or libtool, the result always shows
  "partial" RELRO, only.  This is perfectly the expected result of a
  build when hardening-flags are NOT explicitly enabled in spec-file.


Version-Release number of selected component (if applicable):

  redhat-rpm-config-9.1.0-28.fc17.noarch
  redhat-rpm-config-9.1.0-37.1.fc18.noarch
  redhat-rpm-config-9.1.0-45.fc19.noarch
  redhat-rpm-config-9.1.0-45.fc20.noarch


How reproducible:

  always, when a package with hardening-flags enabled builds a lib using
  autotools and/or libtool


Steps to Reproduce:

  1. rpmbuild a random package which ships lib(s) using libtool during
     %%build and explicitly enables hardening-flags

  2. extract the build binary-rpm and run `hardening-check --color --verbose $file`
     on the libs shipped by that pkg

  3. rebuild the same pkg and disable hardening in spec-file

  4. repeat 2. on the new build pkg and compare the results - no difference

  5. rebuild the previous pkg, re-enable hardening and insert this
     scriptlet immediatly after invoking %configure-macro into it's spec-file:
     
       test -f ./libtool && \
       sed -i \
	   -e 's! \\\\\\$compiler_flags ! \\\\\\$CFLAGS \\\\\\$LDFLAGS -Wl,--as-needed&!g' \
           libtool ;

  6. repeat 2. on the new build pkg and compare the results - full hardening


Actual results:

  with hardening disabled, hardening-check reports:
     ...
     Read-only relocations: yes
     Immediate binding: no, not found!

  with hardening enabled, hardening-check reports:
     ...
     Read-only relocations: yes
     Immediate binding: no, not found!

  It's actually the same, which is not expected to be.  The one having hardening enabled
  shows "partial" RELRO, too.


Expected results:

  with hardening enabled, hardening-check reports:
     ...
     Read-only relocations: yes
     Immediate binding: yes

  The way it should be.  Hardening is applied completely.


Additional info:

  At least gdm (libgdm*.so*) and abrtd (libabrt*.so*) are directly affected
  by this bug.

  The attached patch will fix this problem by doing all needed changes without
  doing anything in a hardening-enabled spec-file.  This patch will fix the
  "unused-direct-shlib-dependency"-issue encoutered with some pakages, too.

--- Additional comment from Panu Matilainen on 2013-06-27 07:45:13 EDT ---

Has libtool upstream contacted on this particular issue?

From http://lists.gnu.org/archive/html/bug-libtool/2005-10/msg00003.html:
> This change is not correct, however.
> Linker flags are supposed to be interpreted by `libtool', because it may
> have to adjust (both itself and them).  Having LDFLAGS directly in
> $archive_cmds is just wrong, as it bypasses this.

So the sed-hack does something against upstream intentions, and while it might "fix" the hardening case, who knows what it might break? Not to mention such hacks are fragile to version changes and all.

CC'ing ajax, whose work the hardening-stuff in redhat-rpm-config is.

--- Additional comment from Matthew Miller on 2013-07-03 14:28:48 EDT ---

Can we do a more tailored fix which addresses just the hardening flags and not all of $compiler_flags ?

--- Additional comment from Björn Esser on 2013-07-10 03:33:59 EDT ---

Refactored my patch.  Now it just injects the gcc-spec with hardening ldflags.