Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

quic: remove experimental quic #37067

Open
wants to merge 6 commits into
base: master
from
Open

quic: remove experimental quic #37067

wants to merge 6 commits into from

Conversation

@jasnell
Copy link
Member

@jasnell jasnell commented Jan 25, 2021

The OpenSSL OMC has not yet committed to landing the updated QUIC APIs and has indicated that they will not even look at it until OpenSSL 3.1. With OpenSSL 3.0 beta currently delayed with no clear idea of when it will actually land, the initial QUIC support landed in core has now just become a maintenance burden with no clear idea of when we'd ever be capable of delivering it. This PR, therefore, removes the QUIC support and reverts the patched in modifications to openssl. I will be investigating a userland alternative that does not depend on the built-in openssl bindings.

jasnell added 5 commits Jan 25, 2021
This reverts commit 548790a.
This reverts commit b0d5bfe.
This reverts commit 06c5b53.
@jasnell jasnell changed the title Revert "deps: update patch and docs for openssl update" quic: remove quic Jan 25, 2021
@jasnell jasnell changed the title quic: remove quic quic: remove experimental quic Jan 25, 2021
@tniessen
Copy link
Member

@tniessen tniessen commented Jan 25, 2021

This is unfortunate. Is there any chance BoringSSL might provide QUIC support before OpenSSL does?

@jasnell
Copy link
Member Author

@jasnell jasnell commented Jan 25, 2021

BoringSSL already does. Up to this point, we've been using Akamai's port of the BoringSSL APIs to OpenSSL 1.1.1. However, because we cannot use BoringSSL in supported releases because of the lack of an adequate LTS policy we cannot depend on it.

Copy link
Member

@mcollina mcollina left a comment

lgtm

@tniessen
Copy link
Member

@tniessen tniessen commented Jan 25, 2021

However, because we cannot use BoringSSL in supported releases because of the lack of an adequate LTS policy we cannot depend on it.

Yes, that's always been a problem, but we've still applied numerous patches to allow linking Node.js against BoringSSL. Do you see any way of supporting QUIC only when linking against BoringSSL, e.g., within Electron? Or is it too much of a maintenance burden?

@gengjiawen
Copy link
Member

@gengjiawen gengjiawen commented Jan 26, 2021

However, because we cannot use BoringSSL in supported releases because of the lack of an adequate LTS policy we cannot depend on it.

Yes, that's always been a problem, but we've still applied numerous patches to allow linking Node.js against BoringSSL. Do you see any way of supporting QUIC only when linking against BoringSSL, e.g., within Electron? Or is it too much of a maintenance burden?

Maybe we keep a boringssl deps only for quic part like https://github.com/cloudflare/quiche did.

@jasnell
Copy link
Member Author

@jasnell jasnell commented Jan 26, 2021

Yes, that's always been a problem, but we've still applied numerous patches to allow linking Node.js against BoringSSL. Do you see any way of supporting QUIC only when linking against BoringSSL, e.g., within Electron? Or is it too much of a maintenance burden?

That's entirely up to the @nodejs/tsc as whole. We apply patches to support BoringSSL but that's a far cry from shipping supported features that only work with BoringSSL when we do not ship any officially supported releases that use BoringSSL.

@Trott
Trott approved these changes Jan 26, 2021
Copy link
Member

@Trott Trott left a comment

Rubber-stamp LGTM and 😞

@tniessen
Copy link
Member

@tniessen tniessen commented Jan 26, 2021

We apply patches to support BoringSSL but that's a far cry from shipping supported features that only work with BoringSSL when we do not ship any officially supported releases that use BoringSSL.

Sadly, that's true. I am not advocating for officially supporting BoringSSL, I don't think that's reasonable as long as Google doesn't provide LTS support for BoringSSL Also, I had a few discussions with @codebytere about BoringSSL/Electron in the past and IIRC, some Node.js crypto features are unavailable in Electron because BoringSSL does not provide them.

Still, it's sad to not see this progressing in OpenSSL.

@jasnell
Copy link
Member Author

@jasnell jasnell commented Jan 26, 2021

If we're able to see progress made on the openssl side... even just a realistic time frame when we can expect movement towards official support, then we'd have something better to go on. But as it is now, all of this code just ends up being an open ended maintenance burden. Given the amount of work I've done on this, there's literally no one that is more disappointed by this PR than I am.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

6 participants