Open snej opened 4 years ago
FYI, I'm motivated to work on this. If my team ends up choosing Nim to implement a project I'm speccing, we will probably need to use mbedTLS. I'm new to Nim but have a lot of experience with networking in C/C++.
Go for it. Just make sure changes are well tested.
We will probably want #14556 in before getting started on this.
After OpenSSL, GnuTLS appears to be relatively popular, followed by mbedTLS, according to statistics on Debian. Yet, supporting multiple implementations, doing extensive testing, and maintaining them for whole lifetime of the libraries is quite a big amount of work. Are there other programming languages doing that as part of the stdlib?
We really just need to make it pluggable. External implementations can be provided by 3rd party packages.
Are there other programming languages doing that as part of the stdlib?
Go implemented its own TLS package, in keeping with its extreme NIH tendency.
Rust has native_tls which wraps the platform's TLS library, "SChannel on Windows (via the schannel crate), Secure Transport on OSX (via the security-framework crate), and OpenSSL (via the openssl crate) on all other platforms". But it does not appear to be part of the standard library as its repo is outside the Rust org on Github.
Please support this issue.
per https://github.com/nim-lang/Nim/pull/17741#issuecomment-823928586 there's some tentative support from Araq for something approximating this. To keep momentum, would someone with more skin in the game/experience than I be willing to write an RFC?
I think it would be neat to have libtls API. Applications such as HTTPS can easily (and correctly) be built on top of it.
Summary
Nim's TLS/SSL support is currently hardwired to use OpenSSL. Some programs may want to use alternate APIs (mbedTLS, wolfSSL, bearSSL, SecureTransport, etc.) for reasons of footprint, compatibility, security, etc. This should be possible without having to modify code in the standard library.
Description
Refactor Nim's socket implementation to split out the OpenSSL-dependent code and put a well-defined API in between, with a mechanism to swap in different implementations of that API, whether in the standard library or application-defined.
Additional Information
Forum comment by leorize: