deps: switch openssl to quictls/openssl
/cc @nodejs/tsc @nodejs/crypto
Yesterday, Akamai and Microsoft announced that they are providing, and will be supporting, a temporary supported fork of OpenSSL 1.1.1 and 3.0.0 that includes the necessary bits to support QUIC implementations.
See @richsalz's tweet here for details: https://twitter.com/RichSalz/status/1367349918671773697
Critically, this fork is intended only as a stopgap to support platforms that wish to deliver QUIC support while the main OpenSSL project is focused on the release of 3.0.0. The only differences this fork will have relative to the main OpenSSL project is the additional pieces necessary for QUIC.
Because both Akamai and Microsoft are using this code in production, they are committing to keeping it up to date with the main OpenSSL releases, so there should not be any lag time between upstream updates and updates in the fork.
Further, Akamai and Microsoft will be requiring that any contributions made to this fork are limited to the QUIC support, and that all other non-QUIC related changes have to be made upstream in the main project. All potential contributors will have to sign and submit the OpenSSL Contributors License Agreement (which I will be doing myself later today).
Now to the point: This pull request replaces the vendored-in OpenSSL distribution in core with the Akamai/Microsoft fork. This does not yet re-introduce the QUIC implementation in Node.js but does make the underlying APIs to do so available by default. If this gets approval and lands, I will start reintroducing the QUIC subsystem in Node.js incrementally over the next few weeks (I have a number of implementation improvements that I've been working on in the interim).
With this version of OpenSSL vendored into core, the QUIC support would be enabled by default as opposed to being opt-in as it was before. For operating systems that use their own distros of Node.js that use the operating system provided openssl (such as RedHat), the QUIC support would not be available unless those distributions provide the option to install the QUIC-enabled openssl alternative. I'm not sure if it's in there yet, but if not I will be opening I have opened a PR soon to add it, but that adds a #DEFINE flag will to be used to conditionally disable building the QUIC support on such platforms.
As for ongoing support, as I mentioned, I will be submitting a signed OpenSSL CLA later today, and will be committing to supporting this for as long as necessary, helping to resolve any issues that may come up while using the fork.
It should be highlighed that for as long as the QUIC subsystem in Node.js is considered experimental, direct use by any Node.js Native Addons of the additional QUIC APIs offered by the fork would also be considered experimental and At Your Own Risk.
Obviously, Long Term Support is a consideration here and I have raised that as a concern in discussions with Akamai and Microsoft. I have communicated to them that if this fork ends up going out in an LTS covered release line that we would need to commit to 30 months of maintenance. While they have not made any guarantees, they are willing to work with us on this, especially if we contribute back to help with that maintenance (thus, part of the reason I'll be signing the CLA). Also, as I said, both companies are using this in production systems today and have their own support and maintenance requirements. Bottom line is that LTS should not be a problem here, especially given that the QUIC support will be considered experimental for quite some time as it matures.
The eventual long term goal is to switch back to the official OpenSSL release once it does include the necessary QUIC support. That will be some time after the 3.0.0 release, with no clear estimate on when that will be.
Source: https://github.com/quictls/openssl/tree/OpenSSL_1_1_1j+quic Signed-off-by: James M Snell jasnell@gmail.com