Double-quoted string (DQS) literals are not allowed by the SQL standard,
which defines that text enclosed in double quotes is to be interpreted
as an identifier only and never as a string literal. Nevertheless, for
historical reasons, SQLite allows double-quoted string literals in some
cases, which leads to inconsistent behavior and subtle bugs.
This commit changes the behavior of the built-in Node.js API for SQLite
such that the DQS misfeature is disabled by default. This is recommended
by the developers of SQLite. Users can explicitly enable DQS for
compatibility with legacy database schemas if necessary.
PR-URL: https://github.com/nodejs/node/pull/55297
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
Reviewed-By: Jake Yuesong Li <jake.yuesong@gmail.com>
Change sourceSQL and expandedSQL from being methods to being
string-valued properties. These fields
- are conceptually properties (and not actions),
- are derived deterministically from the current state of the object,
- require no parameters, and
- are inexpensive to compute.
Also, following the naming conventions of ECMAScript for new features,
most function names should usually contain a verb, whereas names of
(dynamically computed) properties generally should not, so the current
names also seem more appropriate for properties than for functions.
PR-URL: https://github.com/nodejs/node/pull/54721
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
For historical reasons and to maintain compatibibility with legacy
database schemas, SQLite does not enable foreign key constraints by
default. For new applications, however, this behavior is undesirable.
Currently, any application that wishes to use foreign keys must use
PRAGMA foreign_keys = ON;
to explicitly enable enforcement of such constraints.
This commit changes the behavior of the SQLite API built into Node.js
to enable foreign key constraints by default. This behavior can be
overridden by users to maintain compatibility with legacy database
schemas.
PR-URL: https://github.com/nodejs/node/pull/54777
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
I am not sure what exactly the primary use case is for this function
given that the Node.js API is not designed for users to manually bind
parameters of prepared statements, but this at least clarifies what the
function does.
PR-URL: https://github.com/nodejs/node/pull/54685
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Instead of a giant switch statement and a lot of duplicate code, add the
NID and the block cipher mode of operation to the VARIANTS list and use
those fields to perform configuration appropriately.
PR-URL: https://github.com/nodejs/node/pull/53890
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Currently, by default (i.e., when use_big_ints_ has not explicitly been
set to true), reading a SQLite integer value that is not a safe integer
in JavaScript is likely to yield an incorrect number.
Instead, err on the side of caution and throw if the stored integer is
not a safe integer in JavaScript and if use_big_ints_ has not been set
to true.
PR-URL: https://github.com/nodejs/node/pull/53851
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
The Local<Value> returned from ColumnToValue() and ColumnNameToValue()
may be empty (if a JavaScript exception is pending), in which case a
segmentation fault may occur at the call sites, which do not check if
the Local<Value> is empty. Fix this bug returning early if an exception
is pending (as indicated by the Local being empty).
In the long term, these functions should return MaybeLocal instead of
Local, but this patch is supposed to be a minimal bug fix only.
PR-URL: https://github.com/nodejs/node/pull/53850
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
The exact section has changed in recent versions of ECMA-262, so fix the
section number and explicitly mark the edition of the standard to avoid
having to update it in the future.
PR-URL: https://github.com/nodejs/node/pull/53832
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Because call sites check IsNothing() on the return value of
ExportJWKAsymmetricKey() and ignore the boolean value if the return
value is Just (i.e., not nothing), this function must return Nothing()
instead of Just(false) when throwing a JavaScript error.
PR-URL: https://github.com/nodejs/node/pull/53767
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
Reviewed-By: James M Snell <jasnell@gmail.com>
It is confusing to have both ERR_CRYPTO_SCRYPT_INVALID_PARAMETER and
ERR_CRYPTO_INVALID_SCRYPT_PARAMS. The former was the original error
code, added in 371103dae8, but parameter
validation gradually changed and now produces
ERR_CRYPTO_INVALID_SCRYPT_PARAMS for all parameter validation errors
coming from OpenSSL, as well as different error codes for validation
errors coming from JavaScript. The only remaining use of
ERR_CRYPTO_SCRYPT_INVALID_PARAMETER is in the validation logic that
ensures that no two synonymous options were passed. We already have an
error code for that particular case, ERR_INCOMPATIBLE_OPTION_PAIR, so
replace these last instances of ERR_CRYPTO_SCRYPT_INVALID_PARAMETER with
that error code and remove ERR_CRYPTO_SCRYPT_INVALID_PARAMETER. If there
ever is need again for such an error code, we can just use
ERR_CRYPTO_INVALID_SCRYPT_PARAMS.
Refs: https://github.com/nodejs/node/pull/35093
Refs: https://github.com/nodejs/node/pull/21525
Refs: https://github.com/nodejs/node/pull/20816
PR-URL: https://github.com/nodejs/node/pull/53305
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
It is often unnecessary to obtain (shared) ownership of OpenSSL objects
in this code, and it generally is more costly to do so as opposed to
just obtaining a pointer to the respective OpenSSL object. Therefore,
this patch replaces various OpenSSL function calls that take ownership
with ones that do not.
Refs: https://github.com/nodejs/node/pull/53436
PR-URL: https://github.com/nodejs/node/pull/53460
Reviewed-By: Daniel Lemire <daniel@lemire.me>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
These functions generally should not fail, but we also shouldn't ignore
potential failures entirely since security properties of the application
might depend on successful configuration.
This also is consistent with the existing CHECKs in SetMinProto() and
SetMaxProto().
PR-URL: https://github.com/nodejs/node/pull/53459
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
It is often unnecessary to obtain (shared) ownership of OpenSSL objects
in this code, and it generally is more costly to do so as opposed to
just obtaining a pointer to the respective OpenSSL object. Therefore,
this patch replaces various OpenSSL function calls that take ownership
with ones that do not.
PR-URL: https://github.com/nodejs/node/pull/53436
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
Reviewed-By: James M Snell <jasnell@gmail.com>
Both OpenSSL 1.1.1 and 3.x support SSL_get_peer_tmp_key as a replacement
for SSL_get_server_tmp_key. While the old function name still exists as
an alias, it does not accurately reflect the function's behavior
(anymore). Hence, use the new function name here.
PR-URL: https://github.com/nodejs/node/pull/53366
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
The type of the argument `positive` was declared as `boolean|number`,
which is misleading because the function treats it as a boolean only.
Some call sites even passed numbers, specifically, either `0` or `1`,
which happen to work as expected because they are interpreted as `false`
and `true`, respectively. However, passing `2` would silently lead to
unexpected behavior. Thus, strictly make the argument a boolean.
PR-URL: https://github.com/nodejs/node/pull/53307
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
Reviewed-By: Zeyu "Alex" Yang <himself65@outlook.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
When we throw ERR_CRYPTO_INVALID_SCRYPT_PARAMS after a call to
EVP_PBE_scrypt, check if OpenSSL reported an error and if so, append the
OpenSSL error message to the default generic error message. In
particular, this catches cases when `maxmem` is not sufficient, which
otherwise is difficult to identify because our documentation only
provides an approximation of the required `maxmem` value.
Fixes: https://github.com/nodejs/node/issues/53291
PR-URL: https://github.com/nodejs/node/pull/53300
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
The expression containing MAKEFLAGS must be evaluated in a deferred
context for the propagation to work in GNU make. Otherwise, regardless
of the -j value passed to make, ninja will spawn a potentially greater
number of parallel compilation tasks, which can quickly exhaust all
available memory.
PR-URL: https://github.com/nodejs/node/pull/53088
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
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>
This patch adds a V8 fast API implementation for the buffer.compare
binding, which is used both by Buffer.prototype.equals and
Buffer.prototype.compare. In particular, it significantly improves the
performance of comparing buffers for equality.
PR-URL: https://github.com/nodejs/node/pull/52993
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Within Node.js, attempt to determine if libuv is using io_uring. If it
is, disable process.setuid() and other user identity setters.
We cannot fully prevent users from changing the process's user identity,
but this should still prevent some accidental, dangerous scenarios.
PR-URL: https://github.com/nodejs-private/node-private/pull/528
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
CVE-ID: CVE-2024-22017
setuid() does not affect libuv's internal io_uring operations if
initialized before the call to setuid(). This potentially allows the
process to perform privileged operations despite presumably having
dropped such privileges through a call to setuid(). Similar concerns
apply to other functions that modify the process's user identity.
This commit changes libuv's io_uring behavior from opt-out (through
UV_USE_IO_URING=0) to opt-in (through UV_USE_IO_URING=1) until we figure
out a better long-term solution.
PR-URL: https://github.com/nodejs-private/node-private/pull/528
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
CVE-ID: CVE-2024-22017
SYS_capget with _LINUX_CAPABILITY_VERSION_3 returns the process's
permitted capabilities as two 32-bit values. To determine if the only
permitted capability is indeed CAP_NET_BIND_SERVICE, it is necessary to
check both of those values.
Not doing so creates a vulnerability that potentially allows
unprivileged users to inject code into a privileged Node.js process
through environment variables such as NODE_OPTIONS.
PR-URL: https://github.com/nodejs-private/node-private/pull/505
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
CVE-ID: CVE-2024-21892
The permission model's security guarantees fall apart in the presence of
relative symbolic links. When an application attempts to create a
relative symlink, the permission model currently resolves the relative
path into an absolute path based on the process's current working
directory, checks whether the process has the relevant permissions, and
then creates the symlink using the absolute target path. This behavior
is plainly incorrect for two reasons:
1. The target path should never be resolved relative to the current
working directory. If anything, it should be resolved relative to the
symlink's location. (Of course, there is one insane exception to this
rule: on Windows, each process has a current working directory per
drive, and symlinks can be created with a target path relative to the
current working directory of a specific drive. In that case, the
relative path will be resolved relative to the current working
directory for the respective drive, and the symlink will be created
on disk with the resulting absolute path. Other relative symlinks
will be stored as-is.)
2. Silently creating an absolute symlink when the user requested a
relative symlink is wrong. The user may (or may not) rely on the
symlink being relative. For example, npm heavily relies on relative
symbolic links such that node_modules directories can be moved around
without breaking.
Because we don't know the user's intentions, we don't know if creating
an absolute symlink instead of a relative symlink is acceptable. This
patch prevents the faulty behavior by not (incorrectly) resolving
relative symlink targets when the permission model is enabled, and by
instead simply refusing the create any relative symlinks.
The fs APIs accept Uint8Array objects for paths to be able to handle
arbitrary file name charsets, however, checking whether such an object
represents a relative part in a reliable and portable manner is tricky.
Other parts of the permission model incorrectly convert such objects to
strings and then back to an Uint8Array (see 1f64147eb6),
however, for now, this bug fix will simply throw on non-string symlink
targets when the permission model is enabled. (The permission model
already breaks existing applications in various ways, so this shouldn't
be too dramatic.)
PR-URL: https://github.com/nodejs/node/pull/49156
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
This default argument can never benefit any potential caller because any
call site that occurs after this definition will result in a compiler
error due to RadixTree::Lookup(const std::string_view&) now being an
ambiguous call target.
PR-URL: https://github.com/nodejs/node/pull/50736
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Previous security patches addressed path traversal vulnerabilities for
string and Buffer inputs, but ignored Uint8Array inputs. This commit
fixes the existing logic to account for the latter.
The previous implementation would silently ignore unexpected inputs,
whereas this commit introduces an explicit assertion to prevent that
unsafe behavior.
PR-URL: https://github.com/nodejs-private/node-private/pull/456
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
CVE-ID: CVE-2023-39332
Always use the original implementation of pathModule.resolve. If the
application overwrites the value of pathModule.resolve with a custom
implementation, it should not have any effect on the permission model.
PR-URL: https://github.com/nodejs-private/node-private/pull/456
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
CVE-ID: CVE-2023-39331
createDynamicModule() properly escapes import names, but not export
names. In WebAssembly, any string is a valid export name. Importing a
WebAssembly module that uses a non-identifier export name leads to
either a syntax error in createDynamicModule() or to code injection,
that is, to the evaluation of almost arbitrary JavaScript code outside
of the WebAssembly module.
To address this issue, adopt the same mechanism in createExport() that
createImport() already uses. Add tests for both exports and imports.
PR-URL: https://github.com/nodejs-private/node-private/pull/461
Backport-PR-URL: https://github.com/nodejs-private/node-private/pull/489
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
CVE-ID: CVE-2023-39333
Using the JavaScript Hash class is unsafe because its internals can be
tampered with. In particular, an application can cause
Hash.prototype.digest() to return arbitrary values, thus allowing to
circumvent the integrity verification that policies are supposed to
guarantee.
Add and use a new C++ binding internalVerifyIntegrity() that (hopefully)
cannot be tampered with from JavaScript.
PR-URL: https://github.com/nodejs-private/node-private/pull/462
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
CVE-ID: CVE-2023-38552
Much earlier, a design decision was made that the permission model
should not prevent following symbolic links to presumably inaccessible
locations. Recently, after some back and forth, it had been decided that
it is indeed a vulnerability that symbolic links, which currently point
to an accessible location, can potentially be re-targeted to point to a
presumably inaccessible location. Nevertheless, months later, no
solution has been found and the issue is deemed unfixable in the context
of the current permission model implementation, so it was decided to
disclose the vulnerability and to shift responsibiliy onto users who are
now responsible for ensuring that no potentially dangerous symlinks
exist in any directories that they grant access to.
I believe that this design issue might be surprising and that it comes
with significant security implications for users, so it should be
documented.
Original vulnerability report: https://hackerone.com/reports/1961655
PR-URL: https://github.com/nodejs/node/pull/49154
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
As a side effect of 205f1e643e, Node.js
now resolves some paths differently when the permission model is
enabled. While these are mostly edge cases, they are worth mentioning in
the documentation. This commit also adds a known_issues test that
demonstrates one such difference.
PR-URL: https://github.com/nodejs/node/pull/49155
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
The current name is somewhat confusing. There is an internal ByteSource
class, which is entirely unrelated to what IsAnyByteSource() does, even
though both exist in the crypto subsystem of the C++ code. ByteSource
objects can also be constructed from strings, for example, for which
IsAnyByteSource() returns false.
Web IDL calls the types for which this function returns true
BufferSource. This type is commonly used across Web Crypto, for example.
Thus, rename the function to match the Web IDL naming.
Because the function also appears to accept BufferSource objects backed
by SharedArrayBuffer instances, the exact Web IDL name would be
AllowSharedBufferSource, but that seems unnecessarily long, so I decided
to stick with "any".
PR-URL: https://github.com/nodejs/node/pull/49346
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
This only affects the writable side of LazyTransform and should not
change the behavior of any LazyTransform streams (Cipher, Decipher,
Cipheriv, Decipheriv, Hash, Hmac).
If the user does not set defaultEncoding when creating a transform
stream, WritableState uses 'utf8' by default. Only LazyTransform
overwrites this with 'buffer' for strict backward compatibility. This
was necessary when crypto.DEFAULT_ENCODING still existed. Now that
DEFAULT_ENCODING has been removed, defaultEncoding is always 'buffer'.
The writable side of LazyTransform appears to treat 'utf8' and 'buffer'
in exactly the same way. Therefore, there seems to be no need to
overwrite _writableState.defaultEncoding at this point.
Nevertheless, because Node.js has failed to hide implementation details
such as _writableState from the ecosystem, we may want to consider this
a breaking change.
Refs: https://github.com/nodejs/node/pull/47182
Refs: https://github.com/nodejs/node/pull/8611
PR-URL: https://github.com/nodejs/node/pull/49140
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
getDefaultEncoding() always returns 'buffer' in Node.js 20.
In diffiehellman.js, this value is always used as input to either
toBuf(), encode(), or getArrayBufferOrView(). All of these functions
treat any falsy encoding just like 'buffer', so we can safely remove the
calls to getDefaultEncoding().
Refs: https://github.com/nodejs/node/pull/47182
PR-URL: https://github.com/nodejs/node/pull/49169
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
This (not particularly elegant) native addon tests the effect of
UV_THREADPOOL_SIZE on node-api. The test fails if Node.js allows more
than UV_THREADPOOL_SIZE async tasks to run concurrently, or if it limits
the number of concurrent async tasks to anything less than
UV_THREADPOOL_SIZE.
PR-URL: https://github.com/nodejs/node/pull/49165
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
getDefaultEncoding() always returns 'buffer' in Node.js 20. It requires
some careful justification but the default encoding can be eliminated
from sig.js entirely.
In Sign.prototype.update, we can safely remove the conditional
assignment of getDefaultEncoding() to encoding. This is because
SignUpdate() in crypto_sig.cc internally calls node::crypto::Decode,
which returns UTF8 for falsy encoding values. In other words, with the
conditional assignment, StringBytes::Write() ultimately receives the
encoding BUFFER, and without the conditional assignment, it receives the
encoding UTF8. However, StringBytes::Write() treats both encodings
identically, so there is no need to deviate from the internal default
encoding UTF8.
In Sign.prototype.sign, we can also safely remove the conditional
assignment of getDefaultEncoding() to encoding. Whether encoding is
falsy or 'buffer' makes no difference.
In Verify.prototype.verify, we can also safely remove the conditional
assignment of getDefaultEncoding() to sigEncoding. This is because the
function passes the sigEncoding to getArrayBufferOrView(), which passes
it to Buffer.from(). If sigEncoding is 'buffer', getArrayBufferOrView()
instead passes 'utf8' to Buffer.from(). Because the default encoding of
Buffer.from() is 'utf8', passing a falsy encoding to
getArrayBufferOrView() instead of 'buffer' results in the same behavior.
Refs: https://github.com/nodejs/node/pull/47182
PR-URL: https://github.com/nodejs/node/pull/49145
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
When the experimental permission model is enabled, the running
JavaScript code is subject to certain restrictions, all of which can
be bypassed or even disabled by native code due to the nature of the
permission model implementation. That is why Node.js native addons
are disabled by default when the permission model is enabled. However,
the built-in crypto, https, and tls modules still allow loading
custom OpenSSL engines. Because OpenSSL engines can execute arbitrary
(native) code while being loaded by Node.js, this has the same security
implications as allowing native addons. In other words, allowing user
code to load OpenSSL engines at runtime effectively enables bypassing
any supposed security restrictions.
This patch adds appropriate checks before attempting to dynamically
load an OpenSSL engine that throw an error if the permission model is
enabled.
PR-URL: https://github.com/nodejs-private/node-private/pull/409
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
CVE-ID: CVE-2023-30586
Tobias Nießen