quic: start re-enabling and working on quic with openssl 3.5

[jasnell]

Start working on re-enabling QUIC support with the availability of OpenSSL 3.5. This will be a multi-step process.

There are some functional changes here but this is mostly set up to start enabling building the quic mechanisms by default if openssl 3.5.1 or higher is present. Otherwise, all the QUIC stuff will be disabled.

Note that this PR does not fully switch over. The move to the new guard will be incremental, after which the original compile guard will be removed.

Updates the ngtcp2 and nghttp3 dependencies also.

This cannot land until #59234 lands

[nodejs-github-bot]

Review requested:

• @nodejs/gyp
• @nodejs/security-wg

[jasnell]

@nodejs/quic @nodejs/build

@codebytere ... just a heads up since this will impact electron builds using boring... there's some work that'll need to be done to support boring here but it's possible. Specifically, see the edits to ngtcp2.gyp ... and more specifically, there's a comment in there about enabling the boringssl adapter that is provided by ngtcp2.

@richardlau ... it's worth taking a look at the configure.py changes here. If at all possible, I could use some help with supporting openssl shared library builds on this.

[nodejs-github-bot]

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

[richardlau]

@richardlau ... it's worth taking a look at the configure.py changes here. If at all possible, I could use some help with supporting openssl shared library builds on this.

@jasnell (I'm out of office this week, so this is just quick thoughts after glancing at the changes.)

For a shared library build, I'm not sure VERSION.dat will be available, but instead the OpenSSL version should be in opensslv.h. When building a shared library, configure.py works out the include path for the library either through

• specifying as an argument to configure, e.g. --shared-openssl-includes for openssl

  node/configure.py

  Lines 382 to 385 in 405ad4e

  	shared_optgroup.add_argument('--shared-openssl-includes',
  	action='store',
  	dest='shared_openssl_includes',
  	help='directory containing OpenSSL header files')

• or relying on pkg_config

  node/configure.py

  Lines 1670 to 1681 in 405ad4e

  	def configure_library(lib, output, pkgname=None):
  	shared_lib = 'shared_' + lib
  	output['variables']['node_' + shared_lib] = b(getattr(options, shared_lib))
  	if getattr(options, shared_lib):
  	(pkg_libs, pkg_cflags, pkg_libpath, _) = pkg_config(pkgname or lib)
  	if options.__dict__[shared_lib + '_includes']:
  	output['include_dirs'] += [options.__dict__[shared_lib + '_includes']]
  	elif pkg_cflags:
  	stripped_flags = [flag.strip() for flag in pkg_cflags.split('-I')]
  	output['include_dirs'] += [flag for flag in stripped_flags if flag]

  For openssl this happens here:

  node/configure.py

  Line 1831 in 405ad4e

  configure_library('openssl', o)

We can see, for example, https://ci.nodejs.org/job/node-test-commit-linux-containered/51946/nodes=ubuntu2204_sharedlibs_openssl35_x64/consoleFull, that configure knows about the include dirs:

23:24:24 { 'target_defaults': { 'cflags': [],
23:24:24                        'configurations': { 'Debug': { 'v8_enable_v8_checks': 0,
23:24:24                                                       'variables': {}},
23:24:24                                            'Release': { 'v8_enable_v8_checks': 1,
23:24:24                                                         'variables': {}}},
23:24:24                        'default_configuration': 'Release',
23:24:24                        'defines': [ 'NODE_OPENSSL_CONF_NAME=nodejs_conf',
23:24:24                                     'ICU_NO_USER_DATA_OVERRIDE'],
23:24:24                        'include_dirs': ['/opt/openssl-3.5.0/include'],
23:24:24                        'libraries': [ '-L/opt/openssl-3.5.0/lib64',
23:24:24                                       '-lcrypto',
23:24:24                                       '-lssl']},

If ngtcp2 is only needed for quic, maybe we don't need to version check at all for shared library openssl and assume whoever is building is responsible for linking to an appropriate OpenSSL version if quic support is enabled? If they are using a pre-3.5 version of OpenSSL then it's their responsibility to either not configure --with-quic (or configure --without-quic if the default changes).

[jasnell]

it's their responsibility to either not configure --with-quic (or configure --without-quic if the default changes).

I was hoping to be able to do away with these compile guards and based it entirely on whether the version of openssl or boringssl that is used as the appropriate APIs available.. simply because it gives one less knob we have to turn when building. If we cannot reliably detect this, however, then yeah, falling back on these and just requiring whomever is building to provide the right thing would work.

[jasnell]

Just as a heads up to reviewers... while I'm generally not very bullish on AI generated code, I did use copilot/claude to generate this particular function for me. I went through it and the impl appeared reasonable but it's absolutely worth reviewing in detail to make sure it is correct.

[jasnell]

Looking at the CI run, it does look like the check here is still failing for the shared-openssl cases but the build still proceeds since the value is set to 0. This has the side effect of disabling quic in those builds so it's not fatal. Still, would be ideal to figure out a version of this that works. Going to keep iterating but if anyone in @nodejs/build has any suggestions I'd appreciate it :-) .. the key issue is that it's not able to see the include path to find the opensslv.h header in the CI builds here. It looks like our builders aren't using the --shared-openssl-includes option to set that.

[richardlau]

@jasnell The CI builds use pkg-config to get the include paths. I've opened #59353 to fix the OpenSSL version detection for that case.

[jasnell]

Brilliant! Thank you @richardlau !

[jasnell]

Not quite yet. I need to get the implementation updated to use the alternative APIs provided by openssl 3.5, get the build working again, and then finish working on the javascript side of the implementation. Given my current availability it's still likely to be at least a few weeks but my goal is to have it ready to go in time for the 25.0.0 release in October.

[splitice]

Is this going to include a streams implementation or webtransport only?

[m50S79sM6SRNp8Jn]

Is this going to include a streams implementation or webtransport only?

Was there ever any update on your question? Obviously it's not posted here, maybe elsewhere that you know of?