Update Mac versions in helix queues

[agocke]

No description provided.

[Copilot]

Pull Request Overview

This PR updates the Mac versions in the helix queues configuration and adjusts the version numbers for various Mac platforms. The key changes include:

• Updating OSX version numbers for iOS Simulator/Mac Catalyst arm64 queues.
• Modifying OSX version numbers for iOS/tvOS Simulator x64 & MacCatalyst x64 queues.
• Adjusting OSX arm64 and OSX x64 versions for public and internal team projects.

Reviewed Changes

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

File	Description
eng/pipelines/coreclr/templates/helix-queues-setup.yml	Updated OSX version numbers for multiple Mac platform queues
eng/pipelines/libraries/helix-queues-setup.yml	Updated OSX version numbers for multiple Mac platform queues

Comments suppressed due to low confidence (2)

eng/pipelines/coreclr/templates/helix-queues-setup.yml:41

• There appears to be an inconsistency in OSX version numbers: the iOS/tvOS Simulator x64 & MacCatalyst queue is updated to 'OSX.14.Amd64.Open' while the dedicated OSX x64 queue is updated to 'OSX.15.Amd64.Open' further down. Please verify whether these versions should be aligned.

-      - OSX.14.Amd64.Open

eng/pipelines/libraries/helix-queues-setup.yml:105

• The updated version for the iOS/tvOS Simulator x64 & MacCatalyst queue ('OSX.15.Amd64.Open') differs from the corresponding update in the coreclr templates file. Please confirm if this discrepancy is intentional or if both files should use the same OSX version.

-      - OSX.15.Amd64.Open

[dotnet-policy-service]

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

[agocke]

It looks like there are some failing tests on Mac OS for cryptography. @vcsjones do you happen to know any blockers here?

[vcsjones]

No usable version of libssl was found
SIGABRT

These images don't appear to have OpenSSL on them, or its not getting installed correctly.

[vcsjones]

It's not enough to run install-dependencies.sh from arcade. While that does install openssl from Brew, it does not put libssl or libcrypto in a directory where macOS will look.

I don't remember the specifics, but machines appear to need some kind of configuration based on dotnet/dnceng#1625.

[agocke]

What would break if we dropped OpenSSL?

[vcsjones]

What would break if we dropped OpenSSL?

On macOS? We would have no test coverage for classes like RSAOpenSsl and ECDsaOpenSsl on macOS (well, we would need to disable it). These classes are supported on macOS when OpenSSL is present on the system.

[matouskozak]

@agocke fyi: I have a PR for the Apple mobile workloads migration here #113313. Do you want to do it in a single PR here or split it for desktop/mobile?

[agocke]

Mobile can go in separately

[vcsjones]

Circling back around to this...

What would break if we dropped OpenSSL?

OpenSSL on macOS has been dropped.

[ManickaP]

Just a quick question, does this mean we're dropping installing OpenSSL on MAC machines in helix?
Because our QUIC tests depends on MsQuic which in turn depends on system libcrypto (from OpenSSL). So if we're completely dropping OpenSSL from testing MAC machines, we're losing test coverage there.

cc @wfurt, @liveans

[vcsjones]

I should probably document somewhere why S.S.Cryptography decided to finally break with OpenSSL on macOS. I am sure there are better places but let's start here.

As far as @bartonjs and I are aware, recent macOS version on Apple Silicon do not make it feasible to support OpenSSL, at least the way the native shim expects to be able to load it.

Apple Silicon, plus applications built with the Hardened Runtime, on macOS 14 (and perhaps older)+ adjust the system PATH in such a way that we cannot get it to load libcrypto or libssl. The library path searching is

• /System/Volumes/Preboot/Cryptexes/
• /usr/lib
• SxS with executable
• An absolute path

So when the native shim does dlopen("libcrypto.3.dylib") it looks in those paths.

1. It's not in the system cryptex
2. It's not in /usr/lib
3. It's not next to dotnet
4. We don't dlopen with an absolute path because that path is variable.

Traditionally, we expected libssl and libcrypto to just show up in the search path. Usually that meant linking the libraries in /usr/local/lib, or DYLD_LIBRARY_PATH. However both that path and environment variable are ignored by Apple's harden runtime.

Both the cryptex directory and /usr/lib are non-writable directories. Even as root. Apple's SIP protects them. We can't realistically expect libcrypto and libssl to be next to everyone's dotnet application. And we can't use an absolute path because OpenSSL is not really have an "official" place on macOS.

---

I don't know much about how MsQuic works on macOS, how CI or users are expected to acquire all of the dependencies. However if it works similar to the OpenSSL native shim works, it's very difficult to get MsQuic working on a modern MacOS version when it's in a PATH the Apple library loader won't look in.

[ManickaP]

@liveans this ⬆️ might be related to #114912