[release/8.0-staging] Fix copying ephemeral keys to keychains

[github-actions[bot]]

Backport of #106973 to release/8.0-staging

/cc @lewing @vcsjones @bartonjs

Customer Impact

• [X] Customer reported
• [ ] Found internally

Reported by multiple customers in https://github.com/dotnet/runtime/issues/106775.

Customers that use X509Certificate2.CopyWithPrivateKey will get a CryptographicException on macOS Sequoia, which is currently in beta. This breaks some key development scenarios, like CertificateRequest, which is used by ASP.NET for configuring local development HTTPS certificates.

This is due to Apple changing the behavior of one of their APIs to return a different error code. The change is to handle the new error code, in addition to the old one.

Regression

• [ ] Yes
• [ ] No
• [X] Reaction to platform changes in new OS version

Testing

Existing unit tests failed on the new macOS version. The tests now pass on macOS Sequoia.

Risk

Low. This adds an extra condition to an error handling path that already existed.

IMPORTANT: If this backport is for a servicing release, please verify that:

• The PR target branch is release/X.0-staging, not release/X.0.

• If the change touches code that ships in a NuGet package, you have added the necessary package authoring and gotten it explicitly reviewed.

[dotnet-policy-service[bot]]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones See info in area-owners.md if you want to be subscribed.

[carlossanlop]

Friendly reminder that Code Complete for the October Release is September 9. If we want this fix to be included in that release, please merge this PR before that date.

[bartonjs]

/ba-g Unrelated failure

[JohnGalt1717]

Because this wasn't merged you have a disaster on your hands. Please raise to the right people and get a .402 emergency release of the SDK out for mac users.

[jeffhandley]

Hi @JohnGalt1717. Thanks for letting us know this issue is affecting you. The fix is already merged into the next .NET 6 and .NET 8 servicing releases, scheduled for release in October. We recognize that folks who upgraded to macOS Sequoia as soon as it was released are affected and that there isn't general workaround that can be applied. That is why we prioritized getting this fix in place within a few days of the issue being identified in a macOS Sequoia Beta release. The October servicing releases are the earliest possible timing for getting official builds out.

Between now and the October releases, the daily builds out of main do have the fix in place. You could consider installing that daily build and using that build of .NET 9 to unblock local development. You can find those daily builds here at https://github.com/dotnet/sdk/blob/main/documentation/package-table.md#table.

[JohnGalt1717]

Obviously waiting 15-20 DAYS to fix your mistake on this isn’t acceptable and expecting us to use daily builds is also not a reasonable expectation for all of your Mac users.

I strongly encourage you to get an emergency fix out that fixes this.

And obviously, the open question is: did this blow up all rutntime code too which you now have our apps running in Mac completely broken if they use certificates?

If so,(which it appears it is since there is no workaround!) then you have a catastrophic problem that should be involving the highest levels of .net management to get this done immediately.

[richlander]

This break is unfortunate, agreed. We have lots of topics/concerns/shakeholders to balance. We believe that we're taking a reasonable and pragmatic approach to resolving the issue. We all wish we could deliver the patch faster. We're doing the best we can.

I'm locking the issue from this point since the conversation is getting a bit heated.