Open ViktorHofer opened 9 hours ago
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
update the build on all source-built repos so they work without setting OPENSSL_ENABLE_SHA1_SIGNATURES=1
Because SHA1 is insecure, on some systems OpenSSL disallows it. Setting the OPENSSL_ENABLE_SHA1_SIGNATURES=1
makes OpenSSL allow the signature.
Based on https://github.com/dotnet/runtime/issues/65874#issuecomment-1051052527 my understanding is that we don't need the (strong naming) SHA1 signatures when source-building .NET.
If we update the repos so they don't use the SHA1 signatures, setting OPENSSL_ENABLE_SHA1_SIGNATURES=1
will no longer be needed.
If we update the repos so they don't use the SHA1 signatures
Sorry for my ignorance but what does that exactly mean?
Sorry for my ignorance but what does that exactly mean?
My understanding is that it means: not doing the strong naming in source-build configuration.
cc @mmitche @MichaelSimons
Note that we can build the entire runtime repo without having to set OPENSSL_ENABLE_SHA1_SIGNATURES=1
which makes me assume it is doable for other repos too.
The build from the top post failed when doing a non-source-only build. I don't think this should be tied to source-build.
You may still want to do the strong naming for non-source build, I am not sure.
When building the VMR from a GH codespace with
./build.sh --clean-while-building -bl
the builds fails for the aspnetcore repo:Apparently there's a long discussion about this in https://github.com/dotnet/runtime/issues/65874. @tmds mentioned in the last post:
I'm not sure what that exactly means. @tmds can you please elaborate?