-
-
Notifications
You must be signed in to change notification settings - Fork 32k
Introduce configure --disable-openssf-guide or --enable-openssf-guide #121996
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
cc @kulikjak I prefer this option rather than workaround approach for solaris systems. |
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 |
Oh, I am just thinking about applying OpenSSF policy by default from tier 1 to tier 3 by default. The main problem is that we can not catch the issue outside of our tier1 to 3 platforms and it already happens.
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 In short,
|
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. |
Ah, I see. Thanks for the clarification. This seems fine, then.
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). |
Okay, so as the middle ground.
Does it seem fine? |
I agree with what was said here, but it's a different issue from #121979. When you move the check behind I am happy to rebase it onto this though when it gets into |
I agree with this idea. For a majority of options the autoconf check flag should keep builds from failing if the option is not available, and there might be some nuances as pointed out by @kulikjak above. The PR for I like the idea of a single flag to |
I merged the PR #122054 because we need 2 options for the following reasons.
|
@corona10 We can decide for each option going forward which configure option it falls under, but my idea was that in pursuit of #112301 |
@nohlson So if you think that |
To repeat, Is this the intent? If so, it should indeed be documented well. |
@nohlson By the way who is the mentor of GSoC project? |
I think future options enabled should be minimally invasive and we can give the user an opt-out, rather than many performance impacting options that are opt-in, so that if an option does significantly impact benchmarks it would not be included at least for this initial effort. Limiting the options to CPython as @encukou suggests can be implemented and seems to be more in line with the initial goals of #112301. @corona10 the GSoC project mentor is @sethmlarson |
AFAIK: Traditionally on Linux, this kind of options is set by the distro, rather than in the upstream project. (Click to see them if you're curious)
Such a redistributor will want CPython to:
On Windows and Mac, CPython itself is the builder/redistributor, so it's much more important to set the right flags there. It seems Windows is not in scope here, since MSVC uses different flags. When documenting the options, perhaps it would be best to frame these not as “what OpenSSF recommends”, but as “what CPython uses for the python.org releases” and “what we recommend and test for slower but safer builds”. Then there is the of third-party extensions. Good defaults with easy opt-in would probably involve |
As an extension packaging tool, we strictly avoid python3-config since it provides no way to avoid BASECFLAGS. If we don't have access to python3.pc, we do a rather painful hacky rummaging-around through the undocumented internals of sysconfig.get_config_vars() to retrieve the minimal incdir flags. :) In fact, python-config also includes whatever $CFLAGS were exported at the time CPython was built. It's totally unusable. There is no point worrying what additional changes the OpenSSF flavored flags are going to have on it. |
With 046670c now new options only applied to CFLAGS_NODIST. |
Uh oh!
There was an error while loading. Please reload this page.
#112301 has good intentions to make CPython more safe.
But we can not satisfy all platforms.
There are 2 issues with openssf compiler options.
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
The text was updated successfully, but these errors were encountered: