Downgrade our vendored OpenSSL version back to 1.1.1 #1578
Conversation
We need the engine changes that are present in openssl-src-300, which were last in openssl-sys 0.9.71. We can remove this constraint when the problem that produced this rollback is resolved. refs: sfackler/rust-openssl#1578
A recent cargo update caused openssl-sys to do a minor semver update from 0.9.71 -> 0.9.72, but that release downgraded from openssl 3 to openssl 1 to resolve a performance regression: <sfackler/rust-openssl#1578> That in turn caused libssh to fail to build because the ENGINE feature required by libssh isn't compiled in in openssl-src 1 crate when vendoring on windows. For now, my libssh git repo is constrained to openssl-sys 0.9.71, and we're pointing to that from the wezterm repo.
|
May I have some details about the performance regression? Our work requires build support for Windows UWP targets which is introduced in OpenSSL 3, therefore I have to pin version 0.9.71 as a workaround. Would it be better if a feature can be used to allow users to opt-in for OpenSSL 3? |
|
Some examples: The vendored feature is intended to just provide a reasonable version for people that want to get a thing building - I don't think we'll want to formally support multiple variants of it for different versions. If you have specific needs there, I'd recommend not using the vendored feature and instead point openssl-sys to an existing install that you manage. |
|
@sfackler Thanks for the information! Reusing a prebuilt OpenSSL from vcpkg sounds like a good idea for my case. |
note: this pins the openssl crate to workaround the combination of these two issues: refs: sfackler/rust-openssl#1630 refs: sfackler/rust-openssl#1578
If the vendored feature is aimed to make it convenient to build, rather than the recommended way to pull in the best available openssl, could we revisit and reverse this PR? In wezterm I use the vendored feature for macOS and Windows. While wezterm itself doesn't have a preference on the openssl version, one of the deps is https://github.com/wez/libssh-rs/tree/main/libssh-rs-sys which needs a build of openssl that includes the wez/libssh-rs@3dc392c pinned I'd love to remove this pinning! However, it is a huge PITA to do this by providing my own openssl build (as suggested in the comments above), as I'd need to contrive for this to happen for the various combinations/permutations of:
It seems to me that the vendored feature is ideal for resolving this sort of situation, and that if performance were a motivating factor, that would be a good reason to not use the vendored feature and instead use either the system openssl or some other externally provided build. What do you think about this? :) |
|
Want to echo that this was an unexpected breakage to distant and indirectly distant.nvim, which consumes libssh-rs and ssh2-rs and uses the vendored feature of rust-openssl underneath. |
3.0.0 unfortunately seems to have shipped with several major performance regressions. It seems best to temporarily revert the version used by the
vendoredfeature back to 1.1.1 for now. Hopefully an upcoming 3.x.x release will fix the performance issues, at which point we'll switch back.