[release/9.0] Bump OSX.12 helix queues to OSX.13

[steveisok]

No description provided.

[Copilot]

Pull Request Overview

This PR updates macOS Helix CI queue configurations by upgrading from macOS 12.0 to macOS 13 for both ARM64 and x64 architectures across the runtime testing infrastructure.

Key changes:

• Updates macOS Helix queue versions from OSX.1200 to OSX.13
• Applies changes to both public and internal CI queues
• Affects both ARM64 and x64 macOS platforms

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
eng/pipelines/libraries/helix-queues-setup.yml	Updates macOS queue versions for libraries testing on both ARM64 and x64
eng/pipelines/coreclr/templates/helix-queues-setup.yml	Updates macOS queue versions for CoreCLR testing on both ARM64 and x64, covering public and internal projects

[akoeplinger]

this will need the openssl test disabling from #112647

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[steveisok]

This is an infra only change

[akoeplinger]

the osx failure look related

[steveisok]

@vcsjones The quic tests are failing where there is an openssl dependency. I suspect it's not desirable to skip the entire suite outright?

[vcsjones]

The quic tests are failing where there is an openssl dependency. I suspect it's not desirable to skip the entire suite outright?

@ManickaP is this something you know the answer to?

[ManickaP]

Note that it's not just QUIC, but also System.Security.Cryptography.OpenSsl.Tests that are failing (log) with SIGABORT at:

at CryptoInitializer:EnsureOpenSslInitialized <0x0009f>
at CryptoInitializer:.cctor <0x00032>

Is this something known? What are we using for queues in main? Were some fixes done in main? I found #118865, so am I reading it correctly that OpenSSL will never work on Mac anymore? Are we loosing capabilities? Or just test coverage? (Sorry for the barrage of questions, but I don't keep myself up to date with OSX changes).

Lastly, backporting #119273 should help. It will use MsQuic with statically linkes OpenSSL for running tests on OSX.

[steveisok]

Is this something known? What are we using for queues in main? Were some fixes done in main? I found #118865, so am I reading it correctly that OpenSSL will never work on Mac anymore? Are we loosing capabilities? Or just test coverage? (Sorry for the barrage of questions, but I don't keep myself up to date with OSX changes).

Lastly, backporting #119273 should help. It will use MsQuic with statically linkes OpenSSL for running tests on OSX.

I'm pretty sure we dropped the openssl dependency on main. I tried integrating #119273, but that unfortunately does not seem like enough. It's still trying to initialize openssl unsuccessfully in the quic tests.

I think we are going to need to have it installed on the machines in the 13 queue.

[vcsjones]

@steveisok @ManickaP

What are we using for queues in main? Were some fixes done in main?

In main, System.Security completely dropped support for OpenSSL on a Mac. (Explanation later). That happened at #116481, and in #117465, and in #117472.

I think we are going to need to have it installed on the machines in the 13 queue.

The whole reason we made this effort to drop OpenSSL on a Mac is that modern macOS with hardened runtimes make this difficult. On recent macOS + Apple Silicon + Hardened Runtime, Apple no longer looks in /usr/local/lib when loading dynamic libraries. This makes it difficult to actually get OpenSSL in a path that loader will actually look, that we can actually write to (usr/lib is SIP locked, etc). The only feasible place is side-by-side with the native binary, but that's not something a customer is realistically going to do.

@bartonjs and I spent a considerable amount of time trying to figure this out in #113399 (comment).

tl;dr: getting macOS plus OpenSSL from Homebrew to play nicely on .NET is very difficult which is what lead us to dropping it in the first place.

[ManickaP]

I tried integrating #119273, but that unfortunately does not seem like enough. It's still trying to initialize openssl unsuccessfully in the quic tests.

This is weird, because on the very same machine, with the same MsQuic package, the tests run on main, eg.:
https://helixr1107v0xdeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-119673-merge-3ed417e3e6184853be/System.Net.Quic.Functional.Tests/1/console.22289518.log?helixlogtype=result

Console log: 'System.Net.Quic.Functional.Tests' from job 3ed417e3-e618-4853-be46-52ba9a24310a workitem b9f562bd-86e9-4eba-8091-c98406b69248 (osx.13.amd64.open) executed on machine dci-mac-build-206 running macOS-13.7.4
...
MsQuic supported and using 'libmsquic.dylib 2.5.5.0 (b3945bb0c9e44463c93dac13e40975a7c3a526ca)' (OpenSSL).
    System.Net.Quic.Tests.MsQuicPlatformDetectionTests.UnsupportedPlatforms_ThrowsPlatformNotSupportedException [SKIP]
      Condition(s) not met: "IsQuicUnsupported"
MsQuic Counters:
    CONN_CREATED 1608
    CONN_HANDSHAKE_FAIL 25
    CONN_APP_REJECT 8
    CONN_LOAD_REJECT 0

Unobserved exceptions of 0 different types: 

  Finished:    System.Net.Quic.Functional.Tests
=== TEST EXECUTION SUMMARY ===
   System.Net.Quic.Functional.Tests  Total: 428, Errors: 0, Failed: 0, Skipped: 1, Time: 116.491s

And console log from this PR https://helixr1107v0xdeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-119814-merge-fc1956e4f2934e2db4/System.Net.Quic.Functional.Tests/1/console.ba284004.log?helixlogtype=result:

Console log: 'System.Net.Quic.Functional.Tests' from job fc1956e4-f293-4e2d-b47d-d366d91e37e4 workitem 630a15e8-b44a-46ff-8984-e053fbc9b486 (osx.13.amd64.open) executed on machine dci-mac-build-206 running macOS-13.7.4
...
MsQuic supported and using 'libmsquic.dylib 2.5.5.0 (b3945bb0c9e44463c93dac13e40975a7c3a526ca)'.
No usable version of libssl was found
[createdump] Gathering state for process 93157 
[createdump] Crashing thread 147d75 signal 6 (0006)
[createdump] Writing crash report to file /cores/coredump.93157.dmp.crashreport.json
[createdump] Crash report successfully written
[createdump] Writing minidump with heap to file /cores/coredump.93157.dmp
[createdump] Written 487530808 bytes (119026 pages) to core file
[createdump] Target process is alive
[createdump] Dump successfully written in 3757ms
waitpid() returned successfully (wstatus 00000000) WEXITSTATUS 0 WTERMSIG 0
./RunTests.sh: line 182: 93157 Abort trap: 6           "$RUNTIME_PATH/dotnet" exec --runtimeconfig System.Net.Quic.Functional.Tests.runtimeconfig.json --depsfile System.Net.Quic.Functional.Tests.deps.json xunit.console.dll System.Net.Quic.Functional.Tests.dll -xml testResults.xml -nologo -nocolor -notrait category=IgnoreForCI -notrait category=OuterLoop -notrait category=failing $RSP_FILE
/private/tmp/helix/working/B1050989/w/A91B0955/e
----- end Mon Sep 22 10:09:33 EDT 2025 ----- exit code 134 ----------------------------------------------------------

[steveisok]

I tried integrating #119273, but that unfortunately does not seem like enough. It's still trying to initialize openssl unsuccessfully in the quic tests.

This is weird, because on the very same machine, with the same MsQuic package, the tests run on main, eg.: https://helixr1107v0xdeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-119673-merge-3ed417e3e6184853be/System.Net.Quic.Functional.Tests/1/console.22289518.log?helixlogtype=result

In this PR, System.Net.Quic.QuicConnection+SslConnectionOptions.ValidateCertificate ends up calling into a path that leads to Interop+CryptoInitializer.Initialize(). That'll end up failing because it looks for openssl. I bet on main that is no longer the case.

[ManickaP]

In this PR, System.Net.Quic.QuicConnection+SslConnectionOptions.ValidateCertificate ends up calling into a path that leads to Interop+CryptoInitializer.Initialize(). That'll end up failing because it looks for openssl. I bet on main that is no longer the case.

You are right! #117472 changed BuildChainAndVerifyProperties to exactly get rid of dependency on OpenSSL on Mac.
So we have only 2 options: disable QUIC tests on OSX or backport this PR as well. @vcsjones any opinions on this?

[bartonjs]

Well, what it means is that QUIC is broken on macOS without OpenSSL, and as time goes on, that gets closer to 100%. (It probably means no one is actually using QUIC on macOS)

If you think QUIC is supposed to work there, you should backport the change. If you think it is an "experimental, rough edges, OpenSSL is required" thing, then you could decide turning off the tests is more sensible.

Personally, I'd backport the change.

[steveisok]

Well, what it means is that QUIC is broken on macOS without OpenSSL, and as time goes on, that gets closer to 100%. (It probably means no one is actually using QUIC on macOS)

If you think QUIC is supposed to work there, you should backport the change. If you think it is an "experimental, rough edges, OpenSSL is required" thing, then you could decide turning off the tests is more sensible.

Personally, I'd backport the change.

Note, this is also going to apply to 8.0. I'm just using this one to inform the other bump.

I would rather first see if we can get the library installed on the MacOS 13 machines and go from there.

[ManickaP]

an "experimental, rough edges, OpenSSL is required" thing

It kind of is, it's not officially fully supported, but we do not discourage users from it and have a docs how to set it up. Note that this also affects HTTP/3 which is much likely used on OSX than QUIC itself.

Either way, we have coverage in 10.0 and main so it's not such a big problem to just disable it.