quic: remove experimental quic

[jasnell]

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.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/35733/

[tniessen]

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

[jasnell]

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.

[mcollina]

lgtm

[tniessen]

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?

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/35740/

[gengjiawen]

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]

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]

Rubber-stamp LGTM and 😞

[tniessen]

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]

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.

[mhdawson]

Rubber stamp LGTM

[trivikr]

RSLGTM

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/35819/

[jasnell]

Landed in 255d633...290ecb3 ....

Ugh this is painful.