This reverts commit 1daf2e26d221712dfbe72f9f6d2f73ef230cc43c, reversing
changes made to c0c50dfcb70d48e5b79c4ae9f1aa9d339af860b4.
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 glibc DNS client side resolver is vulnerable to a stack-based buffer
overflow when the getaddrinfo() library function is used. Software using
this function may be exploited with attacker-controlled domain names,
attacker-controlled DNS servers, or through a man-in-the-middle attack.
https://googleonlinesecurity.blogspot.co.uk/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
Fixes CVE-2014-8121, CVE-2015-1781 and two unnumbered problems (apparently).
All these commits should be contained in the 2.22 release,
but we don't want that yet due to unresolved locale incompatibilites.
Now development stuff is propagated from the first output,
and userEnvPkgs from the one with binaries.
Also don't move *.la files (yet). It causes problems, and they're small.
- there were many easy merge conflicts
- cc-wrapper needed nontrivial changes
Many other problems might've been created by interaction of the branches,
but stdenv and a few other packages build fine now.
