-
Notifications
You must be signed in to change notification settings - Fork 766
Description
Problem:
We need a clear statement around our intended compatibility with OpenSSL.
- Is there a ceiling?
- Is there a timeline with which we intended to drop OpenSSL support?
Solution:
There are two main consumers of s2n-tls with OpenSSL.
AWS Common Runtime: The common runtime is used in various SDK's. It uses AWS-LC by default, but my understanding is that customers can configure different libcryptos. The path to removing OpenSSL support would involve a "fork" on the CRT side where attempting to build s2n-tls with a different libcrypto would just fall back to an interned copy of AWS-LC.
aws-sdk-cpp: This is the official AWS SDK for C++. My understanding is that this always builds with OpenSSL, because it has a libcurl dependency, and AWS-LC is not compatible with curl Edit: AWS-LC is compatible with Curl. The path to removing OpenSSL support would then entail always interning AWS-LC.
The main downside of interning AWS-LC is increased artifact size. The exact increase is currently unclear. My understanding is that AWS-LC artifact size varies significantly based on Debug Info and Assembly inclusion. To determine the path forward, we should determine
- what is the size increase with a naive implementation, and how many customers can't use that?
- is there a path to keeping our artifact size the same for very restricted customers? Can we make the libs2n artifact smaller to "make room" for the AWS-LC artifact?