Introduce configure --disable-openssf-guide or --enable-openssf-guide

[corona10]

#112301 has good intentions to make CPython more safe.
But we can not satisfy all platforms.

There are 2 issues with openssf compiler options.

1. Performance degradation, there is no measurable impact, but it does not mean that everyone wants this.
2. Build failure, which is not managed by our tier system.

To solve this issue, I would like to recommend to provide
./configure --disable-openssf-guide or ./configure --enable-openssf-guide as optional.

I am not sure which option would be better.

If we choose ./configure --disable-openssf-guide than people should use this flag if the compiler flags does not support their systems or make any issue for their system.
If we choose ./configure --enable-openssf-guide, we will enable these options only for our tier 1 system or only for the CI.

WDYT? @nohlson @vstinner @mdboom

Linked PRs

• gh-121996: Introduce ./configure --disable-openssf-guide option #121997
• gh-121996: Introduce --disable-safety and --enable-slower-safety options #122054
• gh-121996: Fix --disable-safety and --enable-slower-safety options  #122414

[corona10]

cc @kulikjak I prefer this option rather than workaround approach for solaris systems.

[mdboom]

I worry about any more flags that add to the overall CI testing matrix (which already has holes). I'd prefer the approach Victor suggested elsewhere to add configure checks for each of the flags, so that platforms that support them (mainly the Tier 1 platforms) will automatically apply and test them whereever possible.

I think I'd prefer to reserve any configure flags for any extra checks that are known to have a performance impact, rather than ones that should be no cost and work for most people. That suggests a different name, something like --enable-slower-safety or something.

[corona10]

I worry about any more flags that add to the overall CI testing matrix (which already has holes).

Oh, I am just thinking about applying OpenSSF policy by default from tier 1 to tier 3 by default.
So I think that there will be no hole if we can catch them from GA to the build bot because we will not apply the new flag to the any of CIs.

The main problem is that we can not catch the issue outside of our tier1 to 3 platforms and it already happens.

• Solaris: gh-112301: -fstack-protector-strong is also needed in LDFLAGS on Solaris/Illumos #121979
• Compiler issue that didn't catch at GA: Consider applying flags for warnings about potential security issues #112301 (comment)

I know that we can fix them before we officially release the CPython but the problem is that we can not fix the version that we already released, but there are a lot of people who build the CPython from the officially released source code so IMO, so we have to provide a way to solve the issue easily.

So my suggestion is to provide ./configure --disable-openssf-guide and use the flag if the platform does not support our OpenSSF compiler options while they wait for the fixed version.

In short,

• By default: ./configure == ./configure --disable-openssf-policy=no for everywhere.
• If user meet issues for their platform that was not watched by our CI system: use ./configure --disable-openssf-policy if there is no way to build.

[corona10]

That suggests a different name, something like --enable-slower-safety or something

It is possible, but I think we have to define the ground rule about compiler safety options, whether they should be applied by default or optional.
(TBH, by default is ideal..)

[mdboom]

So my suggestion is to provide ./configure --disable-openssf-guide and use the flag if the platform does not support our OpenSSF compiler options while they wait for the fixed version.

Ah, I see. Thanks for the clarification. This seems fine, then.

It is possible, but I think we have to define the ground rule about compiler safety options, whether they should be applied by default or optional. (TBH, by default is ideal..)

I have a more nuanced view. I think by default only if we know there is no runtime performance impact. For those with performance impact, we should hold off on adding them to the defaults until we can eliminate or counteract the performance impact. (There may also be a grey area where we are willing to accept a small performance impact).

[corona10]

Okay, so as the middle ground.

• ./configure --disable-safety: Disable no performance impact compiler options. (CI will not enable this configuration by default)
• ./configure --enable-slower-safety: Enable performance impact compiler options. (We should update the Github Action configuration too)

Does it seem fine?