For historical reasons, the second argument of SSL_CTX_set_timeout is a
signed integer, and Node.js has so far passed arbitrary (signed) int32_t
values. However, new versions of OpenSSL have changed the handling of
negative values inside SSL_CTX_set_timeout, and we should shield users
of Node.js from both the old and the new behavior. Hence, reject any
negative values by throwing an error from within createSecureContext.
Refs: https://github.com/openssl/openssl/pull/19082
PR-URL: https://github.com/nodejs/node/pull/53002
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Tim Perry <pimterry@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/52358
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Jacob Smith <jacob@frende.me>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Our CI already run test files in parallel, having `node:test` spawns
child processes concurrently could lead to oversubscribing the CI
machine. This commit sets the `concurrency` depending
on the presence of `TEST_PARALLEL` in the env, so running the test
file individually still spawns child processes concurrently, and
running the whole test suite does not oversubscribe the machine.
PR-URL: https://github.com/nodejs/node/pull/52177
Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
In the SEA tests, if any of these steps fail:
1. Copy the executable
2. Inject the SEA blob
3. Signing the SEA
We skip the test because the error likely comes from the system or
postject and is not something the Node.js core can fix. We only leave
an exception for a basic test that test injecting empty files as
SEA to ensure the workflow is working (but we still skip if copying
fails or signing fails on Windows).
PR-URL: https://github.com/nodejs/node/pull/51887
Refs: https://github.com/nodejs/node/issues/49630
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
This patch adds support for `sea.getRawAsset()` which is
similar to `sea.getAsset()` but returns the raw asset
in an array buffer without copying. Users should avoid
writing to the returned array buffer. If the injected
section is not marked as writable or not aligned,
writing to the raw asset is likely to result in a crash.
PR-URL: https://github.com/nodejs/node/pull/50960
Refs: https://github.com/nodejs/single-executable/issues/68
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
With this patch:
Users can now include assets by adding a key-path dictionary
to the configuration as the `assets` field. At build time, Node.js
would read the assets from the specified paths and bundle them into
the preparation blob. In the generated executable, users can retrieve
the assets using the `sea.getAsset()` and `sea.getAssetAsBlob()` API.
```json
{
"main": "/path/to/bundled/script.js",
"output": "/path/to/write/the/generated/blob.blob",
"assets": {
"a.jpg": "/path/to/a.jpg",
"b.txt": "/path/to/b.txt"
}
}
```
The single-executable application can access the assets as follows:
```cjs
const { getAsset } = require('node:sea');
// Returns a copy of the data in an ArrayBuffer
const image = getAsset('a.jpg');
// Returns a string decoded from the asset as UTF8.
const text = getAsset('b.txt', 'utf8');
// Returns a Blob containing the asset.
const blob = getAssetAsBlob('a.jpg');
```
Drive-by: update the documentation to include a section dedicated
to the injected main script and refer to it as "injected main
script" instead of "injected module" because it's a script, not
a module.
PR-URL: https://github.com/nodejs/node/pull/50960
Refs: https://github.com/nodejs/single-executable/issues/68
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Implementing the inspector session object as an async resource causes
unwanted context change when a breakpoint callback function is being
called. Modelling the inspector api without the AsyncWrap base class
ensures that the callback has access to the AsyncLocalStorage instance
that is active in the affected user function.
See `test-inspector-async-context-brk.js` for an illustration of the
use case.
PR-URL: https://github.com/nodejs/node/pull/51501
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
In test status files, `$system` will be the OS and not the arch (which
would be `$arch`).
Add missing single-executable-application test to the list of tests
marked flaky on Linux ppc64le.
PR-URL: https://github.com/nodejs/node/pull/51422
Refs: https://github.com/nodejs/node/pull/50828
Refs: https://github.com/nodejs/node/issues/50740
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
- Use spawnSyncAndExitWithoutError to log more information on error.
- Use NODE_DEBUG_NATIVE to log internals
- Skip the test when available disk space < 120MB
PR-URL: https://github.com/nodejs/node/pull/50759
Refs: https://github.com/nodejs/node/issues/50740
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
It seems using ppc alone is not enough. Add ppc64 to be safe.
PR-URL: https://github.com/nodejs/node/pull/50828
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Keyhan Vakil <kvakil@sylph.kvakil.me>
Previously when checking the initial timing we did a lot of checks
after accessing and copying timing.duration and before we check
that timing.duration is roughly the same as performance.now(),
which can lead to flakes if the overhead of the checking is
big enough. Update the test to check timing.duration against
performance.now() as soon as possible when it's copied instead
of computed.
:#
PR-URL: https://github.com/nodejs/node/pull/49892
Refs: https://github.com/nodejs/reliability/issues/676
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
Reviewed-By: Richard Lau <rlau@redhat.com>
Hard code the value of the host parameter to `common.localhostIPv4` in
`server.listen()` and `net.connect()`. This
1. ensures that the client `socket._handle` is not reinitialized during
connection due to the family autodetection algorithm, preventing
`parser.consume()` from being called with an invalid `socket._handle`
parameter.
2. works around an issue in the FreeBSD 12 machine where the stress test
is run where some sockets get stuck after connection.
PR-URL: https://github.com/nodejs/node/pull/49574
Closes: https://github.com/nodejs/node/pull/49565
Fixes: https://github.com/nodejs/node/issues/49564
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Use spawnSyncAndExit() to show more info when the tes fails.
PR-URL: https://github.com/nodejs/node/pull/49561
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Ruy Adorno <ruyadorno@google.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Nitzan Uziely <linkgoron@gmail.com>
If the libuv operations invoked by `readdir`/`opendir` return
`uv_dirent_t` values where the `type` is `UV_DIRENT_UNKNOWN` then a
further `lstat` is issued to fully construct the `Dirent` values. In the
recursive versions of these functions, the `path` parameter was
incorrectly assumed to be the path to the entry when it should be the
path to the directory containing the entry.
Fixes#49499.
PR-URL: https://github.com/nodejs/node/pull/49603
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
V8 now requires code cache to be compiled from an isolate with the
same RO space layout as the one that's going to deserialize the
cache, so for a binary built with snapshot, we need to compile
the code cache using a deserialized isolate.
Drive-by: ignore "useCodeCache" when "useSnapshot" is true because
the compilation would've been done during build time anyway in
that case, and print a warning for it.
PR-URL: https://github.com/nodejs/node/pull/49226
Refs: https://github.com/nodejs/node-v8/issues/252
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Previously the test makes several assumptions about the absolute
values of the nodeTiming fields, which can make the test flaky
on slow machines. This patch rewrites the test to check the
relative values instead. It also updates the test to make it
work with workers instead of directly skipping in workers.
PR-URL: https://github.com/nodejs/node/pull/49197
Refs: https://github.com/nodejs/reliability/issues/638
Reviewed-By: Debadree Chatterjee <debadree333@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Fixs two issues in `TLSWrap`, one of them is reported in
https://github.com/nodejs/node/issues/30896.
1. `TLSWrap` has exactly one `StreamListener`, however,
that `StreamListener` can be replaced. We have not been
rigorous enough here: if an active write has not been
finished before the transition, the finish callback of it
will be wrongly fired the successor `StreamListener`.
2. A `TLSWrap` does not allow more than one active write,
as checked in the assertion about current_write in
`TLSWrap::DoWrite()`.
However, when users make use of an existing `tls.TLSSocket`
to establish double TLS, by
either
tls.connect({socket: tlssock})
or
tlsServer.emit('connection', tlssock)
we have both of the user provided `tls.TLSSocket`, tlssock and
a brand new created `TLSWrap` writing to the `TLSWrap` bound to
tlssock, which easily violates the constranint because two writers
have no idea of each other.
The design of the fix is:
when a `TLSWrap` is created on top of a user provided socket,
do not send any data to the socket until all existing writes
of the socket are done and ensure registered callbacks of
those writes can be fired.
PR-URL: https://github.com/nodejs/node/pull/48969
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Some tests are assuming they will be run from a directory that do not
contain any quote or special character in its path. That assumption is
not necessary, using `JSON.stringify` or `pathToFileURL` ensures the
test can be run whatever the path looks like.
PR-URL: https://github.com/nodejs/node/pull/48958
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
This patch adds snapshot support to single executable applications.
To build a snapshot from the main script when preparing the
blob that will be injected into the single executable application,
add `"useSnapshot": true` to the configuration passed to
`--experimental-sea-config`. For example:
```
{
"main": "snapshot.js",
"output": "sea-prep.blob",
"useSnapshot": true
}
```
The main script used to build the snapshot must invoke
`v8.startupSnapshot.setDeserializeMainFunction()` to configure the
entry point. The generated startup snapshot would be part of the
preparation blob and get injected into the final executable.
When the single executable application is launched, instead of running
the `main` script from scratch, Node.js would instead deserialize the
snapshot to get to the state initialized during build-time directly.
PR-URL: https://github.com/nodejs/node/pull/46824
Refs: https://github.com/nodejs/single-executable/discussions/57
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Due to server response delay, all possible requests are created anyway.
Instead of doing `36 * os.availableParallelism()` requests, use a fixed
number.
Refs: https://github.com/nodejs/node/pull/48078#issuecomment-1568183115
PR-URL: https://github.com/nodejs/node/pull/48292
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: LiviaMedeiros <livia@cirno.name>
Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
