Chapter 7. QA Notices

Table of Contents

Scanelf: Insecure RUNPATHs
Scanelf: Runtime Text Relocations (TEXTRELS)
Scanelf: Executable Stack (EXECSTACK)
Scanelf: Missing Shared Object Name (SONAME)
Scanelf: Missing Needed Entries
Absolute Symlink In Library Directory
Missing Linker Script
Excessive Files in /
Portage Tempdir In Libtool Scripts
Build Warning: Strict Aliasing
Build Warning: Implicit Declarations
Build Warning: Used Uninitialized
Build Warning: Invalid X<=Y<=Z Comparisons
Build Warning: Non-Null Required
Build Warning: Truncating Pointers

Here we'll go over each QA notice and what you (as a developer) can do to fix the issue. If you're a user, you should of course go file a bug. We'll only cover the non-obvious notices here.

In pretty much all cases, you should try and get these issues resolved upstream rather than simply fixing them in our ebuilds.

Scanelf: Insecure RUNPATHs

    QA Notice: The following files contain insecure RUNPATHs
   

Some of the ELFs that would be installed on the system have insecure dynamic RUNPATH tags. RUNPATH tags are a hardcoded list of filesystem paths that will be searched at runtime when the ELF is executed. If the ELF has a world accessible directory hardcoded in it, then a malicious person can inject code at runtime by adding their own libraries to the directory.

Here are some of the common problems and their solutions.

  • Libtool - old versions of libtool would use too many -rpath flags

    Solution: Regenerate the autotool code

  • Perl - some versions of perl would use incorrect -rpath flags

    Solution: Upgrade system perl build modules

  • Crappy build system - the custom build system uses -rpath incorrectly

    Solution: Review the LDFLAGS in the build system and make them not suck

  • Crappy ebuild - the ebuild installs ELFs instead of using the package's build system

    Solution: Fix the crappy ebuild to use the package's build system