rustls 0.23 CryptoProvider panic on Mattermost wss:// connection

[JYeswak]

Problem

Any TLS connection (specifically the Mattermost channel adapter's wss:// WebSocket) causes a tokio worker thread panic:

thread 'tokio-rt-worker' panicked at rustls-0.23.37/src/crypto/mod.rs:249:14:

Could not automatically determine the process-level CryptoProvider from Rustls crate features.
Call CryptoProvider::install_default() before this point to select a provider manually,
or make sure exactly one of the 'aws-lc-rs' and 'ring' features is enabled.

After enough panics accumulate (~50), the process exits. This happens on every startup when [channels.mattermost] is configured with an https:// server URL.

Environment

• v0.5.4 and v0.5.5 Linux x86_64 binaries (both affected)
• Docker on Ubuntu 22.04
• Config has [channels.mattermost] with server_url = "https://chat.example.com"

Root cause

Cargo.toml uses rustls-tls feature for reqwest and rustls-tls-native-roots for tokio-tungstenite, but rustls 0.23+ requires an explicit CryptoProvider to be installed before any TLS operations. The binary doesn't call CryptoProvider::install_default() at startup.

Suggested fix

Add this early in main(), before any async runtime or TLS connections:

rustls::crypto::ring::default_provider().install_default().ok();

Or ensure the ring crate feature is enabled for rustls in Cargo.toml so it auto-installs.

Workaround

Remove [channels.mattermost] from config.toml entirely. This disables native Mattermost DM-to-agent chat but avoids the panic. Slash commands via an external bridge still work.

[komais]

Could not automatically determine the process-level CryptoProvider from Rustls crate features.
Call CryptoProvider::install_default() before this point to select a provider manually, or make sure exactly one of the 'aws-lc-rs' and 'ring' features is enabled.
See the documentation of the CryptoProvider type for more information
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
2026-03-29T14:48:46.203930Z INFO openfang_channels::bridge: Channel adapter feishu stream ended

the same problem occur on feishu channel .
my version is 0.5.1 , and system is ubuntu

[yaobo-lab]

the same problem version is 0.5.1 , and system is ubuntu:

2026-03-30T09:08:24.242168Z INFO openfang_channels::feishu: Feishu adapter authenticated as openfang
2026-03-30T09:08:24.249477Z INFO openfang_api::channel_bridge: feishu channel bridge started
2026-03-30T09:08:24.251831Z INFO openfang_channels::feishu: Starting Feishu WebSocket mode
2026-03-30T09:08:24.274409Z INFO openfang_api::server: OpenFang API server listening on http://127.0.0.1:4200
2026-03-30T09:08:24.274478Z INFO openfang_api::server: WebChat UI available at http://127.0.0.1:4200/
2026-03-30T09:08:24.274490Z INFO openfang_api::server: WebSocket endpoint: ws://127.0.0.1:4200/api/agents/{id}/ws
2026-03-30T09:08:24.353170Z INFO openfang_channels::feishu: Connecting to Feishu WebSocket endpoint: wss://msg-frontier.feishu.cn/ws/v2?fpid=xxx

thread 'tokio-rt-worker' (119500) panicked at /data/rust/cargo/registry/src/mirrors.ustc.edu.cn-5857e57f01837ef8/rustls-0.23.37/src/crypto/mod.rs:249:14:

Could not automatically determine the process-level CryptoProvider from Rustls crate features.
Call CryptoProvider::install_default() before this point to select a provider manually, or make sure exactly one of the 'aws-lc-rs' and 'ring' features is enabled.
See the documentation of the CryptoProvider type for more information.

note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
2026-03-30T09:08:24.443280Z INFO openfang_channels::bridge: Channel adapter feishu stream ended
2026-03-30T09:08:24.444495Z INFO openfang_kernel::background: Starting continuous background loop agent=clip-hand id=4c8e030a-f47a-4264-bfc6-f517bf5025e6 interval_secs=60
2026-03-30T09:08:24.945503Z INFO openfang_kernel::kernel: Started 3 background agent loop(s) (staggered)

[benhoverter]

Just to bump this issue: The same panic reproduces on macOS aarch64 in v0.5.6 with the Discord integration.
The sequence: Discord gateway URL obtained → channel bridge starts → TLS handshake attempt → panic → stream immediately ends. The daemon catches the crash and keeps running, but Discord never reconnects after that.

[jaberjaber23]

Fixed by PR #1024 which calls rustls::crypto::ring::default_provider().install_default() at kernel boot.