-
Notifications
You must be signed in to change notification settings - Fork 94
Implement old version fallback using dlsym
#223
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Does the library work on 10.12 without the OSX_10_14 feature? It seems to me that if 10.12 support is required, then they shouldn't be configuring the library to require 10.14 as the minimum OS version. I get that Cargo features are a pain, but that's the interface we have to work with. I could add some compatibility workarounds for older OSes when the OSX_10_14 feature is disabled. Having hacks for older OSes when the "I don't need the hacks for older OSes" feature is enabled goes against its purpose. |
The tests do not pass because they expect specific error messages on cert validation failure (which
That's what I was arguing for, yeah. The problem with disabling the To be clear, the ideal solution to me would be something like the following: #[cfg(feature = "OSX_10_14")]
{
SecTrustEvaluateWithError(...); // Use directly
}
#[cfg(not(feature = "OSX_10_14"))]
{
let fnptr = dlsym(RTLD_DEFAULT, c"SecTrustEvaluateWithError".as_ptr());
// ...
} |
(FYI, there's RFC 3750 for adding something like |
rustls-platform-verifier
(nowadays used in major Rust projects like Rustup) usessecurity-framework
, and enables the"OSX_10_14"
Cargo feature.As such, trying to run
rustup update
on a machine with macOS 10.12 installed (which the Rust project otherwise still supports) results in the following dynamic linker error:And trying to compile it manually results in a static linker error:
This could of course be "fixed" in
rustls-platform-verifier
by simply not enabling the feature at all, but there's (probably) a reason why they've chosen to do so. Ideally, we should be able to useSecTrustEvaluateWithError
when available, and only need to fall back toSecTrustEvaluate
when not available.Weak linking offers such a mechanism, though it has been unstable for years with difficult blockers, so another solution would be to look the symbol up dynamically using
dlsym
. Something like the following would work:The text was updated successfully, but these errors were encountered: