For 11.x, the default minimum is TLSv1, so it needs a CLI switch to
change the default to the more secure minimum of TLSv1.2.
PR-URL: https://github.com/nodejs/node/pull/26951
Reviewed-By: Rod Vagg <rod@vagg.org>
Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com>
TLSv1.3 is still supported when explicitly configured, but it is not the
default.
PR-URL: https://github.com/nodejs/node/pull/26951
Reviewed-By: Rod Vagg <rod@vagg.org>
Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com>
This introduces TLS1.3 support and makes it the default max protocol,
but also supports CLI/NODE_OPTIONS switches to disable it if necessary.
TLS1.3 is a major update to the TLS protocol, with many security
enhancements. It should be preferred over TLS1.2 whenever possible.
TLS1.3 is different enough that even though the OpenSSL APIs are
technically API/ABI compatible, that when TLS1.3 is negotiated, the
timing of protocol records and of callbacks broke assumptions hard-coded
into the 'tls' module.
This change introduces no API incompatibilities when TLS1.2 is
negotiated. It is the intention that it be backported to current and LTS
release lines with the default maximum TLS protocol reset to 'TLSv1.2'.
This will allow users of those lines to explicitly enable TLS1.3 if they
want.
API incompatibilities between TLS1.2 and TLS1.3 are:
- Renegotiation is not supported by TLS1.3 protocol, attempts to call
`.renegotiate()` will always fail.
- Compiling against a system OpenSSL lower than 1.1.1 is no longer
supported (OpenSSL-1.1.0 used to be supported with configure flags).
- Variations of `conn.write('data'); conn.destroy()` have undefined
behaviour according to the streams API. They may or may not send the
'data', and may or may not cause a ERR_STREAM_DESTROYED error to be
emitted. This has always been true, but conditions under which the write
suceeds is slightly but observably different when TLS1.3 is negotiated
vs when TLS1.2 or below is negotiated.
- If TLS1.3 is negotiated, and a server calls `conn.end()` in its
'secureConnection' listener without any data being written, the client
will not receive session tickets (no 'session' events will be emitted,
and `conn.getSession()` will never return a resumable session).
- The return value of `conn.getSession()` API may not return a resumable
session if called right after the handshake. The effect will be that
clients using the legacy `getSession()` API will resume sessions if
TLS1.2 is negotiated, but will do full handshakes if TLS1.3 is
negotiated. See https://github.com/nodejs/node/pull/25831 for more
information.
Backport-PR-URL: https://github.com/nodejs/node/pull/26951
PR-URL: https://github.com/nodejs/node/pull/26209
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rod Vagg <rod@vagg.org>
Correctly document the default maxBuffer size for execSync,
execFileSync, and spawnSync. It is 200 * 1024, not Infinity.
Add tests to verify behaviour is as documented.
PR-URL: https://github.com/nodejs/node/pull/22894
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Signed-off-by: Beth Griggs <Bethany.Griggs@uk.ibm.com>
The diagnostic report currently contains command line
information, and the environment, which contains the PWD
environment variable. This combination covers the majority
of cases, but it would be useful to have the result of
uv_cwd() as an additional data point. This commit adds that
information.
PR-URL: https://github.com/nodejs/node/pull/27022
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Signed-off-by: Beth Griggs <Bethany.Griggs@uk.ibm.com>
Make notes about `TypeError` conditions in `Buffer.from()` variants
more accurate.
PR-URL: https://github.com/nodejs/node/pull/27030
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Signed-off-by: Beth Griggs <Bethany.Griggs@uk.ibm.com>
This has been warning for long enough, without any API changes
in the last few months.
PR-URL: https://github.com/nodejs/node/pull/26581
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Signed-off-by: Beth Griggs <Bethany.Griggs@uk.ibm.com>
- Add missing argument
- Reword a sentence
- Rename the `res` argument to `info` in the example to avoid confusion
PR-URL: https://github.com/nodejs/node/pull/27009
Fixes: https://github.com/nodejs/node/issues/26905
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Signed-off-by: Beth Griggs <Bethany.Griggs@uk.ibm.com>
This publicly documents that adding native module names will resolve
the added entry instead of the native module.
It also updates the description why extensions are deprecated.
PR-URL: https://github.com/nodejs/node/pull/26971
Refs: https://github.com/nodejs/node/pull/25362
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Signed-off-by: Beth Griggs <Bethany.Griggs@uk.ibm.com>
This was eligible to begin deprecation in Node 8.
PR-URL: https://github.com/nodejs/node/pull/26982
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Signed-off-by: Beth Griggs <Bethany.Griggs@uk.ibm.com>
Instead of sharing the OS-backed store for all `process.env` instances,
create a copy of `process.env` for every worker that is created.
The copies do not interact. Native-addons do not see modifications to
`process.env` from Worker threads, but child processes started from
Workers do default to the Worker’s copy of `process.env`.
This makes Workers behave like child processes as far as `process.env`
is concerned, and an option corresponding to the `child_process`
module’s `env` option is added to the constructor.
Fixes: https://github.com/nodejs/node/issues/24947
PR-URL: https://github.com/nodejs/node/pull/26544
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Signed-off-by: Beth Griggs <Bethany.Griggs@uk.ibm.com>
The reference is confusing because the object is actually of class
SecureContext. There is no object with class "credentials".
See: https://github.com/nodejs/node/issues/20432#issuecomment-441819285
PR-URL: https://github.com/nodejs/node/pull/26908
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Another nail in the coffin here, farewell ye ol C-style apis.
These apis caused numerous other issues that required far too many
safeguards. This gets us one step closer to not having to worry about
those issues anymore.
Refs: https://github.com/nodejs/node/pull/18066
Refs: https://github.com/nodejs/node/pull/20298
PR-URL: https://github.com/nodejs/node/pull/26760
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
This change allows passing private key objects to
crypto.createPublicKey, resulting in a key object that represents a
valid public key for the given private key. The returned public key
object can be used and exported safely without revealing information
about the private key.
Backport-PR-URL: https://github.com/nodejs/node/pull/26688
PR-URL: https://github.com/nodejs/node/pull/26278
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
It is possible to require the 'process' module and with the upcoming
support for ES Modules, importing 'process' might be the more favorable
way for developers. This commit adds that option to the documentation.
PR-URL: https://github.com/nodejs/node/pull/26792
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
`error` event on each kind of stream is optionally emitted when
`.destroy()` method is called. It depends on `._destroy()`
implementation. In default implementation this event will no be
fired unless `error` parameter has been provided.
It was already mentioned for `writable.destroy([error])`, so I
just copied same sentence for the other streams.
PR-URL: https://github.com/nodejs/node/pull/26589
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
This adds support to enforce a specific color depth by checking the
`FORCE_COLOR` environment variable similar to `chalk`.
On top of that we also add support for the `NO_COLOR` environment
variable as suggested by https://no-color.org/.
PR-URL: https://github.com/nodejs/node/pull/26485
Refs: https://github.com/nodejs/node/pull/26248
Reviewed-By: Roman Reiss <me@silverwind.io>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
The object returned by `child_process.spawnSync()` can have the `status`
property set to `null` if the process terminated due to a signal. We
even test for this in
test/parallel/test-child-process-spawnsync-kill-signal.js.
Update the documentation to reflect this.
PR-URL: https://github.com/nodejs/node/pull/26680
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Use "RFC 1234" instead of "rfc1234", "RFC1234" or similar variants.
PR-URL: https://github.com/nodejs/node/pull/26727
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
