Since 9aee0f3, vendored OpenSSL is built and statically linked into the resulting executable. Most of the time, this is undesired, as it requires the executable to be rebuilt whenever a (security) bug is discovered in OpenSSL. Plus, it makes it more difficult for package maintainers to know whether this package and the resulting executables are affected by such issues.
While I understand that you wanna provide zero-dependency, pre-built executables, this behavior should not be the default. Instead, either Rustls (default-tls reqwest feature) or dynamically-linked OpenSSL (native-tls reqwest feature) should be the default. Although Rustls is better than OpenSSL, FIPS compliance requires OpenSSL.
To satisfy all the requirements, a compile-time feature flag that'd allow for changing the TLS engine used by reqwest should be added.
Since 9aee0f3, vendored OpenSSL is built and statically linked into the resulting executable. Most of the time, this is undesired, as it requires the executable to be rebuilt whenever a (security) bug is discovered in OpenSSL. Plus, it makes it more difficult for package maintainers to know whether this package and the resulting executables are affected by such issues.
While I understand that you wanna provide zero-dependency, pre-built executables, this behavior should not be the default. Instead, either Rustls (
default-tlsreqwest feature) or dynamically-linked OpenSSL (native-tlsreqwest feature) should be the default. Although Rustls is better than OpenSSL, FIPS compliance requires OpenSSL.To satisfy all the requirements, a compile-time feature flag that'd allow for changing the TLS engine used by reqwest should be added.