Fix _FORTIFY_SOURCE macros

This commit fixes the mistake with the use of fortify source security mitigation. Instead of -FORTIFY_SOURCE=2 the mitigation should be enabled with a -D_FORTIFY_SOURCE=2 flag which defines the macro that is later used by the libc library so that secure versions of the functions are used (see e.g. https://github.com/search?q=repo%3Abminor%2Fglibc%20FORTIFY_SOURCE&type=code).

Note that this didn't fire off a compiler warning/error because -F<directory> is a genuine flag in compilers.

From man gcc:

-Fdir
   Add the framework directory dir to the head of the list of directories to be
   searched for header files.  These directories are interleaved with those specified
   by -I options and are scanned in a left-to-right order.

From man clang:

-F<directory>
   Add the specified directory to the search path for framework include files.

Additionally, to really enable the fortify source mitigation, one has to enable optimizations. But this is already done here as the -O2 flag is passed along in CFLAGS.

It may also be good to start using the recently added level 3 of fortify source mitigation by using the -D_FORTIFY_SOURCE=3 flag with -O2 or -O3. However, this requires fairly recent compiler and may add runtime overhead. You can read more about it here: https://developers.redhat.com/blog/2021/04/16/broadening-compiler-checks-for-buffer-overflows-in-_fortify_source.

Last but not least, you can also see the result of the correct vs incorrect macro along with optimizations and no optimizations on this screenshot (source):

While this screenshot doesn't show an example with -FORTIFY_SOURCE=2, you can check it yourself on godbolt.org.

kometchtech / docker-build

Fix _FORTIFY_SOURCE macros #50