GeezerVison

@corona10 can we test with buildbots?

🤖 New build scheduled with the buildbot fleet by @corona10 for commit 453e34f 🤖

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

All commit authors signed the Contributor License Agreement.

@nohlson I will take a look at this PR by this weekend, sorry, I am too busy these days.

@nohlson I have 2 questions.

1. Is this flag the subset of the overall policy that we want to measure?
   Consider applying flags for warnings about potential security issues #112301 (comment)
2. Do you have a plan to provide some kind of ./configure --disable-openssf-guide?

1. This is a subset of the overall policy based on the OpenSSF guidance.
2. I do not intend to add an argument to configure to turn off these options, however I would be interested in maybe including the ability to disable the new options that do impact performance benchmarks. This is theoretically one of those options however we didn't see a measurable impact. I could see there being a configure argument that disables the performance impacting options if we were to introduce one that has a measurable impact.

I would prefer the options we introduce for this effort to be always on, and put a lot of consideration into benchmark impacting options we do include, and possibly not enabling them if we deem the impact too much rather than enabling everything and making a new configure argument.

@nohlson

I do not intend to add an argument to configure to turn off these options, however I would be interested in maybe including the ability to disable the new options that do impact performance benchmarks.

I am pretty sure that there will be users who want to disable options that we added for the OpenSSF guide with a single configuration command :)
Adding the optional argument will be helpful to them(even if enabling OpenSSF options is more recommended), I will submit the PR in this week.

This change broke RHEL8 buildbot, test_cext and test_cppext fail with:

  /usr/include/features.h:393:5: error: #warning _FORTIFY_SOURCE > 2 is treated like 2 on this platform [-Werror=cpp]
   #   warning _FORTIFY_SOURCE > 2 is treated like 2 on this platform
       ^~~~~~~
  cc1plus: all warnings being treated as errors

@nohlson Would you like to check?

I suggest checking for the FORTIFY flag using -Werror in configure.

I suggest checking for the FORTIFY flag using -Werror in configure.

We already do.

We already do.

For other flags yes, but apparently, not for _FORTIFY_SOURCE=3:

# Enable flags that warn and protect for potential security vulnerabilities.
# These flags should be enabled by default for all builds.
AX_CHECK_COMPILE_FLAG([-fstack-protector-strong], [BASECFLAGS="$BASECFLAGS -fstack-protector-strong"], [AC_MSG_WARN([-fstack-protector-strong not supported])], [-Werror])
AX_CHECK_COMPILE_FLAG([-Wtrampolines], [BASECFLAGS="$BASECFLAGS -Wtrampolines"], [AC_MSG_WARN([-Wtrampolines not supported])], [-Werror])
AX_CHECK_COMPILE_FLAG([-D_FORTIFY_SOURCE=3], [BASECFLAGS="$BASECFLAGS -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3"], [AC_MSG_WARN([-D_FORTIFY_SOURCE=3 not supported])])