SmtpClientBuilder causes no process-level CryptoProvider available error
Hello,
after I upgrade the crate aws-config to version 1.6.3, I had problems with the SmtpClientBuilder.
Here a minimal example with the corresponding panic output:
use mail_send::SmtpClientBuilder;
use std::time::Duration;
fn main() {
let _client_builder = SmtpClientBuilder::new("smtp-mail.outlook.com", 587)
.implicit_tls(false)
.credentials(("user", "pw"))
.timeout(Duration::from_secs(15));
println!("Hello, world!");
}
Cargo.toml
[package]
name = "test-tmp"
version = "0.1.0"
edition = "2024"
[dependencies]
mail-send = "0.5.1"
aws-config = {version="1.6.3", features=["behavior-version-latest"]}
Panic:
titan@MacBook-Pro-2 test-tmp % cargo run
Compiling test-tmp v0.1.0 (/Users/titan/it-financeflow/ember/ember-backend/libs/test-tmp)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.27s
Running `target/debug/test-tmp`
thread 'main' panicked at /Users/titan/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rustls-0.23.27/src/crypto/mod.rs:249:14:
no process-level CryptoProvider available -- call CryptoProvider::install_default() before this point
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I see two problems here:
- Adding a library like
aws-configcauses a CryptoProvider issue. I don't know if this is caused by the ´aws-config` cratres configuration. But maybe we can fix this issue on mail-send site. - I see no reason, why the Builder should touch any TLS related logic which triggers the CryptoProvider issue. Until that point of the provider configuration I still could plan to open a plain connection. So why was rustls logic already called at this point of time?
I'm getting the same issue after upgrading lapin from 2.5.0 to 3.0.0, I had to revert to 2.5.0.
See this thread for answers.
See this thread for answers.
Is this really related? My main problem is that there happens TLS stuff but I don't use TLS functionality of the crate in some cases, but the default_crypto stuff still causes problem. This seems not reasonable.
There are multiple crypto backends available and you need to tell rust-tls which one to use.
There are multiple crypto backends available and you need to tell rust-tls which one to use.
I know that, but I don't know why a TLS free connection (or more specific a Builder which does not set a TLS option) expects a crypto provider to...
I haven't tested this but if you are seeing that error on plain text connections then it means that rustls is validating the backends even when it is not used. If that is the case, then unfortunately that can't be fixed from this crate. It would require adding an additional Cargo feature to disable TLS completely.
I still can not understand why it is intended that the check happens during you build up a builder...