Module tls 

Shared rustls ClientConfig for every wire HTTPS surface.

Why this exists

Pre-#176 wire used reqwest’s rustls-tls-native-roots feature, which loads the OS native trust store via rustls-native-certs. That gave us corporate-CA / AV-resign transparency for free in shell-launched daemons. But once #170’s --all-sessions supervisor moved every daemon into launchd, every TLS handshake to wireup.net failed UnknownIssuer: launchd-spawned processes on macOS don’t inherit the operator’s Aqua-session keychain context, so the system query returned an empty root set.

#176 unblocked the supervisor by swapping the reqwest feature to rustls-tls-webpki-roots (Mozilla bundled CA set) and accepting the corp-CA trade-off. This module restores both behaviours: webpki bundled roots are ALWAYS loaded (works in any process context); the OS native trust store is ALSO loaded when accessible (corp CAs + AV-resign keep working in shell context, gracefully empty in launchd). reqwest consumes the resulting rustls::ClientConfig via its use_preconfigured_tls builder method.

Design

• One ClientConfig per process, cached. Building a RootCertStore walks ~200 webpki roots + however many native certs are accessible; ~3–5 ms cost. We pay it once per process. Every relay_client::build_blocking_client call clones a shared Arc<ClientConfig>.
• Fail-soft on native-cert errors. If rustls-native-certs panics, returns Err, or returns malformed certs, we log and fall through to webpki-roots only. Better one missing corp CA than no HTTPS at all.
• WIRE_INSECURE_SKIP_TLS_VERIFY=1 still works — handled at the relay_client::build_blocking_client layer via reqwest’s danger_accept_invalid_certs(true). This module’s config is only consulted when the env var is unset.

Functions

shared_client_config

Return the shared Arc<ClientConfig> — built lazily on first call, cached for the process lifetime.