-
Notifications
You must be signed in to change notification settings - Fork 132
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
[main] CI build failure in CentOSStream9_Offline_x64 leg #3202
Comments
This feels like dotnet/runtime#65874. Is there an |
Yes there is
|
So far I've verified that this is caused by a newer version of the Centos Stream 9 Docker image referenced in the pipeline: https://github.com/dotnet/dotnet/blob/46a1c2be501862fa56901c9c127d875750a37012/src/installer/eng/pipelines/templates/stages/vmr-build.yml#L17 For reference, the build for .NET 7 is successful because it uses an older version of the Docker image: In addition, I also verified that setting I'll investigate further to see what I can find about the difference between the two Docker image versions that caused this to occur. |
I've identified that the regression occurred as a result of the difference between these two images:
I'll dig into those to see what I find for differences. |
CentOS Stream 9 is based on RHEL 9's development branch - it tracks what will release as the next minor update for RHEL 9.x. The first image, based on the date, was built on/around 2022-01-07. RHEL 9.0 was released in May 2022. So the first Centos Stream 9 image is actually a snapshot of a pre-GA release of of a RHEL 9. This commit to OpenSSL 3.0 in CentOS Stream 9 (and in RHEL 9.0) disabled SHA1 as a crypto algorithm in many (but not all) configurations. It was made in February 2022, so it was not present in the first container image. Strong naming needs SHA1, so with SHA1 disabled, it's broken. There's more details on the Strong Naming and CentOS Stream 9/RHEL 9 interaction at dotnet/runtime#65874, including, I think our plan to eventually use PublicSigning by default when building .NET on non-Windows using source-build. There's also #2907 that's about getting source-build to use PublicSign everywhere. |
Full Signing requires RSA+SHA1 which is disabled in some environments (eg, RHEL 9, CentOS Stream 9). Expose a top-level flag to allow that to be disabled easily by users. The actual implementation of that flag is not here; it's in arcade (see dotnet/arcade#12749). Some repos have some nice-to-have fixes (eg, dotnet/source-build-reference-packages#566), but it's mostly optional. The bootstrap arcade SDK being used to build this needs needs to contain the changes for us to be able to build SBRP and then arcade and then all the other repos that will use arcade. For more context around RSA+SHA1 and the alternative (using public signing), see: - dotnet/runtime#65874 - dotnet/source-build#3202 - dotnet/arcade#12515
Full Signing requires RSA+SHA1 which is disabled in some environments (eg, RHEL 9, CentOS Stream 9). Default to turning it off. Expose a top-level property to allow Full Signing to be re-enabled by users. The actual implementation of that flag is not here; it's in arcade (see dotnet/arcade#12749). Some repos have some nice-to-have fixes (eg, dotnet/source-build-reference-packages#566), but it's mostly optional. The bootstrap arcade SDK being used to build this needs needs to contain the changes for us to be able to build SBRP and arcade; then all the other repos that will use the just-built arcade. For more context around RSA+SHA1 and the alternative (using public signing), see: - dotnet/runtime#65874 - dotnet/source-build#3202 - dotnet/arcade#12515
Full Signing requires RSA+SHA1 which is disabled in some environments (eg, RHEL 9, CentOS Stream 9). Default to turning it off. Expose a top-level property to allow Full Signing to be re-enabled by users. The actual implementation of that flag was in dotnet#12749 (commit 3840d43). Once a version of arcade including this fix is used to build the individual repos (in source-build mode) or the VMR, everything should default to public signing. For more context around RSA+SHA1 and the alternative (using public signing), see: - dotnet/runtime#65874 - dotnet/source-build#3202 - dotnet#12515 - dotnet/installer#15873
Full Signing requires RSA+SHA1 which is disabled in some environments (eg, RHEL 9, CentOS Stream 9). Default to turning it off. Expose a top-level property to allow Full Signing to be re-enabled by users. The actual implementation of that flag was in dotnet#12749 (commit 3840d43). Once a version of arcade including this fix is used to build the individual repos (in source-build mode) or the VMR, everything should default to public signing. For more context around RSA+SHA1 and the alternative (using public signing), see: - dotnet/runtime#65874 - dotnet/source-build#3202 - dotnet#12515 - dotnet/installer#15873
Full Signing requires RSA+SHA1 which is disabled in some environments (eg, RHEL 9, CentOS Stream 9). Default to turning it off. Expose a top-level property to allow Full Signing to be re-enabled by users. The actual implementation of that flag was in dotnet#12749 (commit 3840d43). Once a version of arcade including this fix is used to build the individual repos (in source-build mode) or the VMR, everything should default to public signing. For more context around RSA+SHA1 and the alternative (using public signing), see: - dotnet/runtime#65874 - dotnet/source-build#3202 - dotnet#12515 - dotnet/installer#15873
Full Signing requires RSA+SHA1 which is disabled in some environments (eg, RHEL 9, CentOS Stream 9). Default to turning it off. Expose a top-level property to allow Full Signing to be re-enabled by users. The actual implementation of that flag was in #12749 (commit 3840d43). Once a version of arcade including this fix is used to build the individual repos (in source-build mode) or the VMR, everything should default to public signing. For more context around RSA+SHA1 and the alternative (using public signing), see: - dotnet/runtime#65874 - dotnet/source-build#3202 - #12515 - dotnet/installer#15873
There is currently a build failure in the CentOSStream9_Offline_x64 leg in CI (internal Microsoft link). No Other CI leg is encountering this error.
The text was updated successfully, but these errors were encountered: