On Tue, Dec 18, 2012 at 1:48 PM, Bob Friesenhahn <bfriesen@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 18 Dec 2012, Jeffrey Walton wrote: >> >> If you are going to try the waters with warnings, you should also >> consider the flags to integrate with platform security. >> >> Platform security integration includes fortified sources and stack >> protectors. Here are the flags of interest: >> * -fstack-protector-all >> * -z,noexecstack >> * -z,noexecheap (or other measure, such as W^X) >> * -z,relro >> * -z,now >> * -fPIE and -pie for executables >> >> FORTIFY_SOURCE=2 (FORTIFY_SOURCE=1 on Android 4.1+), where available. > > I understand your concern and the reasoning, but these sort of options are > highly platform/target/distribution specific. It is easy to create packages > which fail to build on many systems. Later, the baked in settings of > somewhat dated distribution tarballs may not meet current standards. > > Surely it is better to leave this to OS distribution maintainers who > establish common rules for OS packages and ensure that options are applied > in a uniform and consistent manner. I think your arguments make a lot of sense and I would like to agree with you. Unfortunately, the folks at Red Hat provided a "proof by counter example" with the recent MySQL 0-days (http://www.h-online.com/security/news/item/MariaDB-fixes-zero-day-vulnerability-in-MySQL-1761451.html). I would have expected Red Hat security folks to be on top of it, especially with a high risk application such as a database that accepts input from the network (some hand waiving since PHP is likely in front of it). In the recent MySQL 0-days, the developers (MariaDB) and the platform (Red Hat) both failed. Its been repeated time and time again throughout our brief history. Jeff _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
