Unsupported on macOS 10.12

[madsmtm]

rustls-platform-verifier enables the OSX_10_14 Cargo feature of security-framework, which causes its use to abort on macOS 10.12 (the minimum supported version by rustc) with e.g.:

dyld: Symbol not found: _SecTrustEvaluateWithError
  Referenced from: /Users/madsmtm/.cargo/bin/rustup
  Expected in: /System/Library/Frameworks/Security.framework/Versions/A/Security

Because the SecTrustEvaluateWithError symbol is assumed to be available.

Disabling the feature makes a few error values worse (since security-framework now falls back to calling SecTrustEvaluate), though it's unclear to me if there's anything else affected by it? Would you accept a PR that does not enable this feature flag?

Git blame reveals this to be present since the original commit, CC @complexspaces.

See also kornelski/rust-security-framework#223.

[djc]

So you want this project to support an OS from 9 years ago, not just the one from 7 years ago? By what reference/policy does the Rust project still support 10.12?

[djc]

Also, somewhat relevant that the macOS on x64 target that supports 10.12 is getting demoted to tier 2 (with host tools) soon:

rust-lang/blog.rust-lang.org#1666 (comment)

[madsmtm]

So you want this project to support an OS from 9 years ago, not just the one from 7 years ago?

I want rustup to support the same version as the rest of Rust's host tooling (rustc, cargo, rustfmt) does (and this project is used by rustup). Or at least that we document it here that the support policy for host tooling is something else ;)

By what reference/policy does the Rust project still support 10.12?

The reference is the rustc platform support page. The policy is non-existent, basically "until we decide to drop support". Last version bump was in rust-lang/rust#104385.

Also, somewhat relevant that the macOS on x64 target that supports 10.12 is getting demoted to tier 2 (with host tools) soon.

Yeah, I'm aware. I opened this because I maintain that target, and now that the automated testing is being disabled, it'll become increasingly useful for me to use rustup on the x86 machine under my desk (which runs macOS 10.12).

[ctz]

I think it is very difficult for us to support platforms that we cannot test in CI, and doing that is especially important if contributors do not and cannot use that combination as their daily-driver.

One thing we could consider here is actually withdrawing platform verifier support for x86_64-apple-darwin, and adding it to the list of platforms that use rustls-native-certs and the webpki verifier. That has a much smaller platform footprint (so we still have the CI problem, but hopefully on a smaller scale).

[djc]

One thing we could consider here is actually withdrawing platform verifier support for x86_64-apple-darwin, and adding it to the list of platforms that use rustls-native-certs and the webpki verifier. That has a much smaller platform footprint (so we still have the CI problem, but hopefully on a smaller scale).

This makes sense to me.

[complexspaces]

I am not supportive of withdrawing support for x86_64 macOS, I feel like something has been misunderstood here. macOS 26 is going to be the last release to support x64 but that hasn't even come out stably yet. Very few application developers and distributors will be dropping support for macOS 11, 12, 13, 14, 15, and 26 instantly upon the release of macOS 27 next year (2026) just to remove their x64 build, its too large of a supported user range to drop.

This means that its still important for this crate to support x64 macOS the platform-specific way. I see no reason why rustls-platform-verifier not being able to run x64 macOS in CI should determine this, we aren't using any architectures-specific tricks that would break on x64 but not ARM64. All we care about is Security.framework symbol availability. On top of all that, old OSes won't have unexpected changes to library behavior because they aren't being changed anymore 🙂.

[djc]

That's also fair! But what do you think about macOS 10.12 support?

[complexspaces]

My personal stance is that I am not 100% against supporting a fallback to the older API as long as some things work out to reduce our maintenance burden for a platform even Firefox has dropped:

• We don't need two different error mapping blocks that are completely different
• We write the code to fail opportunistically if we get back a result we aren't quite sure how to handle, even if this means false-negative verification failures, to make sure that its very clear reading the code that it will never let a bad certificate verify successfully as defense in-depth.
• We add a testing-only feature to the crate that lets us add a CI job that forces the old path to be taken for coverage, at least until Apple actually removes the symbol from the SDK (its still there even today AFAICT).

As I mentioned above, I'm not especially worried about older OSes breaking our implementation:

On top of all that, old OSes won't have unexpected changes to library behavior because they aren't being changed anymore 🙂.

macOS <=10.15 are now 100% unmaintained so that old function is never going to have its behavior changed on OS versions we would actually use it.

Summarized my biggest concerns are maintainability for myself and the other macOS contributors and being extra defensive against bad certificates.

Git blame reveals this to be present since the original commit

That's correct, @madsmtm. When the Apple implementation was originally written inside of 1Password our minimum supported macOS version was 10.15, so enabling the static linkage was perfectly acceptable. As you mentioned, the big difference between the old and new evaluation function is error granularity. As far as I know it should be possible to get out the error codes we need to keep the mapping the same but I haven't investigated that in-depth due to no employer interest in that backwards compatibility.