Now it's not an actual archive but a linker script, and the absolute
paths in there were broken due to moving *.a into $static.
Let's fix this up in all *.a in case there are more in future.
This reverts commit 1daf2e26d2, reversing
changes made to c0c50dfcb7.
It seems this is what has been causing all the reliability problems
on Hydra. I'm currently unable to find why it happens, so I'm forced
to revert the update for now. Discussion: #22874.
Enables previously manually disabled stackprotector and stackguard
randomization.
From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511811:
If glibc is built with the --enable-stackguard-randomization option,
each application gets a random canary value (at runtime) from /dev/urandom.
If --enable-stackguard-randomization is absent, applications get a static
canary value of "0xff0a0000". This is very unfortunate, because the
attacker may be able to bypass the stack protection mechanism, by placing
those 4 bytes in the canary word, before the actual canary check is
performed (for example in memcpy-based buffer overflows).
This addresses the following security advisories:
+ CVE-2016-3075: Stack overflow in _nss_dns_getnetbyname_r
+ CVE-2016-1234: glob: buffer overflow with GLOB_ALTDIRFUNC due to incorrect
NAME_MAX limit assumption
+ CVE-2016-3706: getaddrinfo: stack overflow in hostent conversion
Patches cherry-picked from glibc's release/2.23/master branch.
The "glob-simplify-interface.patch" was a dependency for
"cve-2016-1234.patch".
The following parameters are now available:
* hardeningDisable
To disable specific hardening flags
* hardeningEnable
To enable specific hardening flags
Only the cc-wrapper supports this right now, but these may be reused by
other wrappers, builders or setup hooks.
cc-wrapper supports the following flags:
* fortify
* stackprotector
* pie (disabled by default)
* pic
* strictoverflow
* format
* relro
* bindnow
The importance of glibc makes it worthwhile to provide debug
symbols. However, this revealed an issue with separateDebugInfo: it
was indiscriminately adding --build-id to all ld invocations, while in
fact it should only do that for final links. Glibc also uses non-final
("relocatable") links, leading to subsequent failure to apply a build
ID ("Cannot create .note.gnu.build-id section, --build-id
ignored"). So now ld-wrapper.sh only passes --build-id for final
links.
