Several crates:
- tls-api — TLS API without any implementation and without dependencies
- tls-api-native-tls — implementation of TLS API over native-tls crate
- tls-api-openssl — implementation of TLS API over openssl crate
- tls-api-rustls — implementation of TLS API over rustls crate
- tls-api-schannel — missing implementation of TLS API over schannel crate
- tls-api-security-framework — missing implementation of TLS API over security framework crate
- tls-api-native-tls — stub API implementation which returns an error on any operation
- tokio-tls-api — fork of tokio-tls which uses tls-api instead of native-tls
If you develop a library, you do not know which TLS library your user would like to use, and if they need any TLS library at all.
Because of that some libraries simply depend on specific TLS implementations, while others provide "features" to turn on specific dependencies.
It makes development for both library authors and library users inconvenient.
Both authors and users need to configure "features" in Cargo.toml and #[cfg] in code.
For example, your library need to support three options: use openssl, use native-tls, and
no TLS at all. So you need to compile your library three times to check it can be compiled
properly with all three options.
Library authors simply write the code with tls-api library. Since tls-api is
lightweight, library authors can simply write code using it, and have no configuration options.
Library users simply call that library with different implementations of connectors and acceptors.
api-test contains tests implementation independent of any library. And identical tests which use:
| openssl | native-tls | rustls | |
|---|---|---|---|
| Can fetch google.com:443 | Yes | Yes | Yes |
| Server works | Yes | Yes | No |
| ALPN | Yes | No | No |
native-tls uses security-framework on OSX, and security-framework does not support ALPN.
Or you simply want to have an option to avoid building TLS library.