Remove _FORTIFY_SOURCES from build:

[seelabs]

This option is silently ignorned at -O0 on ubuntu. On fedora, we get a warning that requires compiling with optimization (-O).

I see two options:

1. Increase the optimization level to -O1 when debugging
2. Remove _FORTIFY_SOURCES

I'm opting for (2). We have been building this way since at least Oct/2014 and the clang sanitizers serve a similar function.

[willwray]

👍

__FORTIFY_SOURCES should be removed from the debug build __FORTHWITH. This gcc/clang option is intended to fortify release builds against buffer overflow exploits. The utility of fortifying debug builds is unclear, and, as @seelabs points out, it was disabled anyway by the change to the -O flag.

We should consider adding such 'security'/'hardening'/'fortification' options on release builds instead.

Notes

gcc/clang have 'fortified' default configuration on some platforms and so rippled currently builds on those platforms with source code hardening anyways, intended or not.
(I have an Ubuntu distro with __FORTIFY_SOURCES and -fstack-protector-strong set by default; rippled release builds contain many chk calls and debug builds have __stack_chk_fail in almost all *.o's.)

clang sanitizers are a different thing again. They do not yet support source fortification as this issue shows:
google/sanitizers, Support source fortification

A suggestion from Jakub Jelinek:

Well, -D_FORTIFY_SOURCE=2 does things that asan doesn't and can't do, so disabling fortification if you build with -fsanitize=address sounds like a very bad idea to me.

Links

Enhance application security with FORTIFY_SOURCE

"Strong" stack protection for GCC; -fstack-protector options that complement __FORTIFY_SOURCE.

un-fortifying-rippled stackoverflow question (incidentally, perhaps he wanted to unfortify rippled so that he could test exploits for attacking unfortified instances).

[MarkusTeufelberger]

See #1432 (reported in December 2015)

Edit: -Og would be better for debugging than -O1, but apparently there were some issues.

[scottschurr]

As a side note, I noticed that a scons debug build has "+DEBUG" appended to the --version command result. A debug cmake build, built as "cmake -Dtarget=clang.debug.nounity" does not append "+DEBUG" to the version. Just an interesting observation...

[scottschurr]

I'm fairly confident this has nothing to do with your change, but the Travis GCC Coverage build has had an internal compiler error building server.o three times in a row. It's vaguely possible that we need to split the server.cpp unity file into two pieces...

[scottschurr]

👍 Other than the Travis build problem this change looks good to me. I built clang.debug.nounity and clang.release using both scons and cmake on OS X. No warnings on any of the builds. Unit tests ran on all builds.

[seelabs]

@scottschurr Thanks for the note about the cmake build. I'll open an issue.

[codecov-io]

Current coverage is 71.00% (diff: 100%)

Merging #1812 into develop will increase coverage by 0.01%

@@            develop      #1812   diff @@
==========================================
  Files           869        869          
  Lines         69535      69535          
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits          49363      49376    +13   
+ Misses        20172      20159    -13   
  Partials          0          0          

Powered by Codecov. Last update d51a278...e60981f

[nbougalis]

Merged as b0704b4