When establishing a TLS connection to a server with `autoSelectFamily`
set to `true`, the `net.Socket` will call `[kWrapConnectedHandle]()` to
reinitialize the socket (in case if it got broken during previous
connect attempts). Unfortunately, prior to this patch this resulted in a
brand new `TLSWrap` instance being created for the socket. While most of
the configuration of `TLSWrap` is restored, the `servername` was sadly
dropped and not reinitalized.
With this patch `servername` will be reinitialized if there are
`tls.connect` options present on the `TLSSocket` instance, making it
possible to connect with "Happy Eyeballs" to TLS servers that require
the servername extension.
PR-URL: https://github.com/nodejs/node/pull/48255
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Minwoo Jung <nodecorelab@gmail.com>
When `autoSelectFamily` is set to `true`, `net.connect` is supposed to
try connecting to both IPv4 and IPv6, interleaving the address types.
Instead, it appears that the array that holds the addresses in the order
they should be attempted was never used after being populated.
PR-URL: https://github.com/nodejs/node/pull/48258
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
We should set v8_enable_webassembly=false when lite mode is enabled,
since v8_enable_lite_mode implies v8_jitless, and wasm currently
doesn't work with jitless. This is automatically handled in gn, but
seems to be not the case in gyp. Enabling lite mode without setting
v8_enable_webassembly=false leads to "Warning: disabling flag
--expose_wasm due to conflicting flags" at runtime.
PR-URL: https://github.com/nodejs/node/pull/48248
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Incremental compilation of Node.js is slow. Currently on a powerful
Linux machine, it takes about 5.8 seconds to compile
`gen/node_snapshot.cc` with g++.
As in the previous PR which dealt with `node_js2c`, we add a new build
define `NODE_MKSNAPSHOT_USE_STRING_LITERALS` which is used by
`node_mksnapshot`. When this flag is set, we emit string literals
instead of array literals for the snapshot blob and for the code cache,
i.e.:
```c++
// old: static const uint8_t X[] = { ... };
static const uint8_t *X = "...";
```
I only enabled the new flag on Linux/macOS, since those are systems that
I have available for testing. On my Linux system with gcc, it speeds up
compilation of this file by 3.7s (5.8s -> 2.1s). On my Mac system with
clang, it speeds up compilation by 1.7s (3.4s -> 1.7s).
Again, the right thing here is probably to generate separate files for
the snapshot blob and for each code cache output, but this is a nice
intermediate speedup.
Refs: https://github.com/nodejs/node/issues/47984
Refs: https://github.com/nodejs/node/pull/48160
PR-URL: https://github.com/nodejs/node/pull/48162
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
When using OpenSSL 3, Node.js supports FIPS 140-2 when used with an
appropriate OpenSSL 3 provider. It is no longer necessary to rebuild
Node.js with different build time options.
Add a section on how to configure Node.js to use an OpenSSL 3 FIPS
provider to the documentation for the `crypto` module.
PR-URL: https://github.com/nodejs/node/pull/48194
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
With the default security level (SECLEVEL=2), the following error
```
40E72B52DB7F0000:error:0A00018A:SSL routines:tls_process_ske_dhe:dh key
too small:../deps/openssl/openssl/ssl/statem/statem_clnt.c:2100
```
is raised on on Ubuntu 22.04 on WSL2.
PR-URL: https://github.com/nodejs/node/pull/48192
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Remove broken link to deprecated keygen element.
Replacing the link with something to the relevant
part of the HTML spec might be OK, but I don't think
it's necessary. People who need to know will find it
and everyone else should be discouraged from using
this.
Support for the keygen element was removed from Chrome in 2017
and removed from Firefox in 2019. We might consider deprecating
and removing support ourselves, or at least marking the API
as legacy.
Refs: https://caniuse.com/?search=keygen
PR-URL: https://github.com/nodejs/node/pull/48176
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
This commit addresses a scrolling/flickering issue in the HTML version
of the docs. By adding `auto` to the `contain-intrinsic-size` CSS
property, we're asking the browser to remember the last-rendered size
for the element (once it's been rendered) instead of forcing the browser
to treat it as being 1px by 5000px when it goes offscreen.
PR-URL: https://github.com/nodejs/node/pull/48195
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
I recently discovered that the custom NodeJS specific OpenSSL
config section in openssl.cnf would not be respected, if the
environment variable `NODE_EXTRA_CA_CERTS` was set.
This happens even if it contains an invalid value, i.e no actual
certs are read.
Someone suggested moving the checking of extra ca certs to after
the OpenSSL config is read, and this seems to work.
PR-URL: https://github.com/nodejs/node/pull/48159
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Minwoo Jung <nodecorelab@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
This PR is a follow-up of #46615.
When bumping V8 for node 18, various bugs appeared around vm.
Some have been fixed along the flow, but there is at least one
remaining and described at:
https://github.com/facebook/jest/issues/13338.
The current fix does nothing on node 20: the new bump of v8 done for
node 20 seems to fix it. But it would fix the problem in both node 18
and node 19. I confirmed it would fix node 19 by cherry-picking the
commit on v19.x-staging and launching `make -j4 jstest` on it.
PR-URL: https://github.com/nodejs/node/pull/47572
Reviewed-By: James M Snell <jasnell@gmail.com>
dependabot[bot]