GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — crypto: avoid hang when no algorithm available by richardlau · Pull Request #46237 · nodejs/node

Conversation

@richardlau

@richardlau richardlau commented Jan 17, 2023

Copy link
Copy Markdown
Member

Avoid an endless loop if no algorithm is available to seed the cryptographically secure pseudorandom number generator (CSPRNG).

Co-authored-by: Anna Henningsen [email protected]
Fixes: #46200


cc @nodejs/crypto I believe the existing looping is to cope with transient not-enough-entropy cases but it's unclear to me how to recreate those and whether those cases are distinct enough from the two cases that his PR addresses (see the test case). As @addaleax mentions in #46200 (comment), hopefully scoping this change to a specific error will limit the scope for unintended breakage.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

addaleax and bricss reacted with heart emoji
All reactions
  • ❤️ 2 reactions
@richardlau @addaleax
crypto: avoid hang when no algorithm available
58dca48
Avoid an endless loop if no algorithm is available to seed the
cryptographically secure pseudorandom number generator (CSPRNG).

Co-authored-by: Anna Henningsen <[email protected]>
@nodejs-github-bot

nodejs-github-bot commented Jan 17, 2023

Copy link
Copy Markdown
Collaborator

Review requested:

  • @nodejs/crypto
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@nodejs-github-bot nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. crypto Issues and PRs related to the crypto subsystem. needs-ci PRs that need a full CI run. labels Jan 17, 2023
addaleax
addaleax approved these changes Jan 17, 2023
View reviewed changes
@addaleax addaleax added the request-ci Add this label to start a Jenkins CI on a PR. Only starts once the PR has an approving review. label Jan 17, 2023
@github-actions github-actions Bot removed the request-ci Add this label to start a Jenkins CI on a PR. Only starts once the PR has an approving review. label Jan 17, 2023
@nodejs-github-bot

This comment was marked as outdated.

Sign in to view
@richardlau
fixup! crypto: avoid hang when no algorithm available
a954614
@richardlau

richardlau commented Jan 17, 2023

Copy link
Copy Markdown
Member Author

Pushed a fixup since crypto.setFips isn't supported in workers.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@richardlau richardlau added commit-queue-squash PRs the Commit Queue should land as one squashed commit. request-ci Add this label to start a Jenkins CI on a PR. Only starts once the PR has an approving review. labels Jan 17, 2023
@github-actions github-actions Bot removed the request-ci Add this label to start a Jenkins CI on a PR. Only starts once the PR has an approving review. label Jan 17, 2023
@nodejs-github-bot

This comment was marked as outdated.

Sign in to view
addaleax
addaleax approved these changes Jan 17, 2023
View reviewed changes
@nodejs-github-bot

This comment was marked as outdated.

Sign in to view
@richardlau richardlau added the author ready PRs with CI started, the required approvals, and no outstanding review comments. label Jan 17, 2023
@github-actions github-actions Bot mentioned this pull request Jan 18, 2023
CI Reliability 2023-01-18 nodejs/reliability#487
Open
18 tasks
bnoordhuis
bnoordhuis reviewed Jan 18, 2023
View reviewed changes
Comment thread src/crypto/crypto_util.cc Resolved

Uh oh!

There was an error while loading. Please reload this page.

@richardlau richardlau removed the author ready PRs with CI started, the required approvals, and no outstanding review comments. label Jan 18, 2023
@richardlau
fixup! crypto: avoid hang when no algorithm available
86fa1f1
addaleax
addaleax approved these changes Jan 18, 2023
View reviewed changes
bnoordhuis
bnoordhuis approved these changes Jan 18, 2023
View reviewed changes
Comment thread test/parallel/test-crypto-no-algorithm.js Resolved

Uh oh!

There was an error while loading. Please reload this page.

@github-actions github-actions Bot mentioned this pull request Jan 19, 2023
CI Reliability 2023-01-19 nodejs/reliability#488
Open
14 tasks
@lpinca lpinca added the request-ci Add this label to start a Jenkins CI on a PR. Only starts once the PR has an approving review. label Jan 19, 2023
@github-actions github-actions Bot removed the request-ci Add this label to start a Jenkins CI on a PR. Only starts once the PR has an approving review. label Jan 19, 2023
@nodejs-github-bot

This comment was marked as outdated.

Sign in to view
@richardlau
fixup! crypto: avoid hang when no algorithm available
cfdea22
@richardlau richardlau added the request-ci Add this label to start a Jenkins CI on a PR. Only starts once the PR has an approving review. label Jan 19, 2023
@RafaelGSS RafaelGSS mentioned this pull request Jan 20, 2023
v19.5.0 proposal #46286
Merged
This was referenced Jan 21, 2023
CI Reliability 2023-01-21 nodejs/reliability#490
Open
CI Reliability 2023-01-22 nodejs/reliability#491
Open
CI Reliability 2023-01-23 nodejs/reliability#492
Open
CI Reliability 2023-01-24 nodejs/reliability#493
Open
CI Reliability 2023-01-25 nodejs/reliability#494
Open
juanarbol pushed a commit that referenced this pull request Mar 3, 2023
@richardlau @addaleax @juanarbol
crypto: avoid hang when no algorithm available
373211e
Avoid an endless loop if no algorithm is available to seed the
cryptographically secure pseudorandom number generator (CSPRNG).

Co-authored-by: Anna Henningsen <[email protected]>
PR-URL: #46237
Fixes: #46200
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
@juanarbol juanarbol mentioned this pull request Mar 3, 2023
V18.15.0 proposal #46920
Merged
juanarbol pushed a commit that referenced this pull request Mar 5, 2023
@richardlau @addaleax @juanarbol
crypto: avoid hang when no algorithm available
91ece41
Avoid an endless loop if no algorithm is available to seed the
cryptographically secure pseudorandom number generator (CSPRNG).

Co-authored-by: Anna Henningsen <[email protected]>
PR-URL: #46237
Fixes: #46200
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
BethGriggs pushed a commit that referenced this pull request Mar 27, 2023
@richardlau @addaleax @BethGriggs
crypto: avoid hang when no algorithm available
de6dd67
Avoid an endless loop if no algorithm is available to seed the
cryptographically secure pseudorandom number generator (CSPRNG).

Co-authored-by: Anna Henningsen <[email protected]>
PR-URL: #46237
Fixes: #46200
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
@BethGriggs BethGriggs mentioned this pull request Mar 27, 2023
v16.20.0 proposal #47272
Merged
mwalbeck pushed a commit to mwalbeck/docker-cyberchef that referenced this pull request Apr 4, 2023
renovate-bot @mwalbeck
Update Node.js to v16.20.0 (#187)
9ec907c
This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [node](https://github.com/nodejs/node) | stage | minor | `16.19.1-bullseye` -> `16.20.0-bullseye` |

---

### Release Notes

<details>
<summary>nodejs/node</summary>

### [`v16.20.0`](https://github.com/nodejs/node/releases/tag/v16.20.0): 2023-03-29, Version 16.20.0 &#x27;Gallium&#x27; (LTS), @&#8203;BethGriggs

[Compare Source](nodejs/node@v16.19.1...v16.20.0)

##### Notable Changes

-   **deps:**
    -   update undici to 5.20.0 (Node.js GitHub Bot) [#&#8203;46711](nodejs/node#46711)
    -   update c-ares to 1.19.0 (Michaël Zasso) [#&#8203;46415](nodejs/node#46415)
    -   upgrade npm to 8.19.4 (npm team) [#&#8203;46677](nodejs/node#46677)
    -   update corepack to 0.17.0 (Node.js GitHub Bot) [#&#8203;46842](nodejs/node#46842)
-   **(SEMVER-MINOR)** **src**: add support for externally shared js builtins (Michael Dawson) [#&#8203;44376](nodejs/node#44376)

##### Commits

-   \[[`de6dd67790`](nodejs/node@de6dd67790)] - **crypto**: avoid hang when no algorithm available (Richard Lau) [#&#8203;46237](nodejs/node#46237)
-   \[[`4617512788`](nodejs/node@4617512788)] - **crypto**: ensure auth tag set for chacha20-poly1305 (Ben Noordhuis) [#&#8203;46185](nodejs/node#46185)
-   \[[`24972164fc`](nodejs/node@24972164fc)] - **deps**: update undici to 5.20.0 (Node.js GitHub Bot) [#&#8203;46711](nodejs/node#46711)
-   \[[`85f88c6a8d`](nodejs/node@85f88c6a8d)] - **deps**: V8: cherry-pick [`90be99f`](nodejs/node@90be99fab31c) (Michaël Zasso) [#&#8203;46646](nodejs/node#46646)
-   \[[`b4ebe6d47b`](nodejs/node@b4ebe6d47b)] - **deps**: update c-ares to 1.19.0 (Michaël Zasso) [#&#8203;46415](nodejs/node#46415)
-   \[[`56cbc7fdda`](nodejs/node@56cbc7fdda)] - **deps**: V8: cherry-pick [`c2792e5`](nodejs/node@c2792e58035f) (Jiawen Geng) [#&#8203;44961](nodejs/node#44961)
-   \[[`7af9bdb31e`](nodejs/node@7af9bdb31e)] - **deps**: upgrade npm to 8.19.4 (npm team) [#&#8203;46677](nodejs/node#46677)
-   \[[`962a7471b5`](nodejs/node@962a7471b5)] - **deps**: update corepack to 0.17.0 (Node.js GitHub Bot) [#&#8203;46842](nodejs/node#46842)
-   \[[`748bc96e35`](nodejs/node@748bc96e35)] - **deps**: update corepack to 0.16.0 (Node.js GitHub Bot) [#&#8203;46710](nodejs/node#46710)
-   \[[`a467782499`](nodejs/node@a467782499)] - **deps**: update corepack to 0.15.3 (Node.js GitHub Bot) [#&#8203;46037](nodejs/node#46037)
-   \[[`1913b6763d`](nodejs/node@1913b6763d)] - **deps**: update corepack to 0.15.2 (Node.js GitHub Bot) [#&#8203;45635](nodejs/node#45635)
-   \[[`809371a15f`](nodejs/node@809371a15f)] - **module**: require.resolve.paths returns null with node schema (MURAKAMI Masahiko) [#&#8203;45147](nodejs/node#45147)
-   \[[`086bb2f8d4`](nodejs/node@086bb2f8d4)] - ***Revert*** "**src**: let http2 streams end after session close" (Rich Trott) [#&#8203;46721](nodejs/node#46721)
-   \[[`6a01d39120`](nodejs/node@6a01d39120)] - **(SEMVER-MINOR)** **src**: add support for externally shared js builtins (Michael Dawson) [#&#8203;44376](nodejs/node#44376)
-   \[[`d081032a60`](nodejs/node@d081032a60)] - **test**: fix test-net-connect-reset-until-connected (Vita Batrla) [#&#8203;46781](nodejs/node#46781)
-   \[[`efe1be47ec`](nodejs/node@efe1be47ec)] - **test**: skip test depending on `overlapped-checker` when not available (Antoine du Hamel) [#&#8203;45015](nodejs/node#45015)
-   \[[`fc47d58abe`](nodejs/node@fc47d58abe)] - **test**: remove cjs loader from stack traces (Geoffrey Booth) [#&#8203;44197](nodejs/node#44197)
-   \[[`cf76d0790d`](nodejs/node@cf76d0790d)] - **test**: fix WPT title when no META title is present (Filip Skokan) [#&#8203;46804](nodejs/node#46804)
-   \[[`0d1485b924`](nodejs/node@0d1485b924)] - **test**: fix default WPT titles (Filip Skokan) [#&#8203;46778](nodejs/node#46778)
-   \[[`088e9cde3d`](nodejs/node@088e9cde3d)] - **test**: add WPTRunner support for variants and generating WPT reports (Filip Skokan) [#&#8203;46498](nodejs/node#46498)
-   \[[`908c4dff44`](nodejs/node@908c4dff44)] - **test**: mark test-crypto-key-objects flaky on Linux (Richard Lau) [#&#8203;46684](nodejs/node#46684)
-   \[[`768e56227e`](nodejs/node@768e56227e)] - **tools**: make `utils.SearchFiles` deterministic (Bruno Pitrus) [#&#8203;44496](nodejs/node#44496)

</details>

---

### Configuration

📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

---

This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNS4yMy4zIiwidXBkYXRlZEluVmVyIjoiMzUuMjMuMyJ9-->

Reviewed-on: https://git.walbeck.it/mwalbeck/docker-cyberchef/pulls/187
Co-authored-by: renovate-bot <[email protected]>
Co-committed-by: renovate-bot <[email protected]>
mwalbeck pushed a commit to mwalbeck/docker-jellyfin-livestream that referenced this pull request Apr 4, 2023
renovate-bot @mwalbeck
Update Node.js to v16.20.0 (#243)
31f455a
This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [node](https://github.com/nodejs/node) | stage | minor | `16.19.1-bullseye-slim` -> `16.20.0-bullseye-slim` |

---

### Release Notes

<details>
<summary>nodejs/node</summary>

### [`v16.20.0`](https://github.com/nodejs/node/releases/tag/v16.20.0): 2023-03-29, Version 16.20.0 &#x27;Gallium&#x27; (LTS), @&#8203;BethGriggs

[Compare Source](nodejs/node@v16.19.1...v16.20.0)

##### Notable Changes

-   **deps:**
    -   update undici to 5.20.0 (Node.js GitHub Bot) [#&#8203;46711](nodejs/node#46711)
    -   update c-ares to 1.19.0 (Michaël Zasso) [#&#8203;46415](nodejs/node#46415)
    -   upgrade npm to 8.19.4 (npm team) [#&#8203;46677](nodejs/node#46677)
    -   update corepack to 0.17.0 (Node.js GitHub Bot) [#&#8203;46842](nodejs/node#46842)
-   **(SEMVER-MINOR)** **src**: add support for externally shared js builtins (Michael Dawson) [#&#8203;44376](nodejs/node#44376)

##### Commits

-   \[[`de6dd67790`](nodejs/node@de6dd67790)] - **crypto**: avoid hang when no algorithm available (Richard Lau) [#&#8203;46237](nodejs/node#46237)
-   \[[`4617512788`](nodejs/node@4617512788)] - **crypto**: ensure auth tag set for chacha20-poly1305 (Ben Noordhuis) [#&#8203;46185](nodejs/node#46185)
-   \[[`24972164fc`](nodejs/node@24972164fc)] - **deps**: update undici to 5.20.0 (Node.js GitHub Bot) [#&#8203;46711](nodejs/node#46711)
-   \[[`85f88c6a8d`](nodejs/node@85f88c6a8d)] - **deps**: V8: cherry-pick [`90be99f`](nodejs/node@90be99fab31c) (Michaël Zasso) [#&#8203;46646](nodejs/node#46646)
-   \[[`b4ebe6d47b`](nodejs/node@b4ebe6d47b)] - **deps**: update c-ares to 1.19.0 (Michaël Zasso) [#&#8203;46415](nodejs/node#46415)
-   \[[`56cbc7fdda`](nodejs/node@56cbc7fdda)] - **deps**: V8: cherry-pick [`c2792e5`](nodejs/node@c2792e58035f) (Jiawen Geng) [#&#8203;44961](nodejs/node#44961)
-   \[[`7af9bdb31e`](nodejs/node@7af9bdb31e)] - **deps**: upgrade npm to 8.19.4 (npm team) [#&#8203;46677](nodejs/node#46677)
-   \[[`962a7471b5`](nodejs/node@962a7471b5)] - **deps**: update corepack to 0.17.0 (Node.js GitHub Bot) [#&#8203;46842](nodejs/node#46842)
-   \[[`748bc96e35`](nodejs/node@748bc96e35)] - **deps**: update corepack to 0.16.0 (Node.js GitHub Bot) [#&#8203;46710](nodejs/node#46710)
-   \[[`a467782499`](nodejs/node@a467782499)] - **deps**: update corepack to 0.15.3 (Node.js GitHub Bot) [#&#8203;46037](nodejs/node#46037)
-   \[[`1913b6763d`](nodejs/node@1913b6763d)] - **deps**: update corepack to 0.15.2 (Node.js GitHub Bot) [#&#8203;45635](nodejs/node#45635)
-   \[[`809371a15f`](nodejs/node@809371a15f)] - **module**: require.resolve.paths returns null with node schema (MURAKAMI Masahiko) [#&#8203;45147](nodejs/node#45147)
-   \[[`086bb2f8d4`](nodejs/node@086bb2f8d4)] - ***Revert*** "**src**: let http2 streams end after session close" (Rich Trott) [#&#8203;46721](nodejs/node#46721)
-   \[[`6a01d39120`](nodejs/node@6a01d39120)] - **(SEMVER-MINOR)** **src**: add support for externally shared js builtins (Michael Dawson) [#&#8203;44376](nodejs/node#44376)
-   \[[`d081032a60`](nodejs/node@d081032a60)] - **test**: fix test-net-connect-reset-until-connected (Vita Batrla) [#&#8203;46781](nodejs/node#46781)
-   \[[`efe1be47ec`](nodejs/node@efe1be47ec)] - **test**: skip test depending on `overlapped-checker` when not available (Antoine du Hamel) [#&#8203;45015](nodejs/node#45015)
-   \[[`fc47d58abe`](nodejs/node@fc47d58abe)] - **test**: remove cjs loader from stack traces (Geoffrey Booth) [#&#8203;44197](nodejs/node#44197)
-   \[[`cf76d0790d`](nodejs/node@cf76d0790d)] - **test**: fix WPT title when no META title is present (Filip Skokan) [#&#8203;46804](nodejs/node#46804)
-   \[[`0d1485b924`](nodejs/node@0d1485b924)] - **test**: fix default WPT titles (Filip Skokan) [#&#8203;46778](nodejs/node#46778)
-   \[[`088e9cde3d`](nodejs/node@088e9cde3d)] - **test**: add WPTRunner support for variants and generating WPT reports (Filip Skokan) [#&#8203;46498](nodejs/node#46498)
-   \[[`908c4dff44`](nodejs/node@908c4dff44)] - **test**: mark test-crypto-key-objects flaky on Linux (Richard Lau) [#&#8203;46684](nodejs/node#46684)
-   \[[`768e56227e`](nodejs/node@768e56227e)] - **tools**: make `utils.SearchFiles` deterministic (Bruno Pitrus) [#&#8203;44496](nodejs/node#44496)

</details>

---

### Configuration

📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

---

This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNS4yMy4zIiwidXBkYXRlZEluVmVyIjoiMzUuMjMuMyJ9-->

Reviewed-on: https://git.walbeck.it/mwalbeck/docker-jellyfin-livestream/pulls/243
Co-authored-by: renovate-bot <[email protected]>
Co-committed-by: renovate-bot <[email protected]>
@richardlau richardlau added backported-to-v16.x and removed lts-watch-v16.x labels Aug 24, 2023
@targos targos added backported-to-v18.x and removed lts-watch-v18.x labels Oct 27, 2023
@colinhacks colinhacks mentioned this pull request Sep 4, 2026
src: seed V8 from the OS CSPRNG instead of OpenSSL's DRBG #65796
Merged
colinhacks added a commit to colinhacks/node that referenced this pull request Sep 4, 2026
@colinhacks
src: seed V8 from the OS CSPRNG instead of OpenSSL's DRBG
043813b
InitializeOncePerProcessInternal() calls CSPRNG(nullptr, 0) to confirm
OpenSSL's random source is seeded and installs a V8 entropy source that
goes through CSPRNG() as well. The first RAND_status() of the process
therefore runs before V8 starts, instantiates the DRBG, and with it
activates the default provider and constructs its algorithm and name
tables (ossl_method_construct, ossl_namemap_stored): 3.7% of the
samples of `node -e 0` on Linux x64, all of it before v8Start.

V8 uses the entropy for hash seeds, address space layout randomization
and Math.random(), none of which are cryptographic, so read the OS
CSPRNG directly through uv_random(). Run the eager seeding check only
when a user-supplied OpenSSL configuration or FIPS could have left
OpenSSL without a DRBG, where an early abort beats a hang at the first
crypto call; Node's own configuration always activates the default
provider, so nothing changes for it except when the first fetch
happens. Every crypto consumer stays on OpenSSL, and a system without
a usable CSPRNG still aborts at startup, now from uv_random() failing.

Measured min of 100 runs, paired against an unpatched build on the
same machine: `node -e 0` 18.35 -> 17.73 ms on Linux x64, nodeStart to
v8Start 2.37 -> 1.62 ms on Linux and 2.48 -> 1.90 ms on macOS arm64.
The startup profile no longer shows RAND_status or the provider
construction; the first crypto.randomBytes() instantiates the DRBG in
0.19 ms. The `parallel`, `sequential`, `message` and `es-module`
suites show no failure the unpatched build does not have.

Refs: nodejs@5cc36c39d2
Refs: nodejs#44493
Refs: nodejs#46237
Signed-off-by: Colin McDonnell <[email protected]>
colinhacks added a commit to colinhacks/node that referenced this pull request Sep 4, 2026
@colinhacks
src: seed V8 from the OS CSPRNG instead of OpenSSL's DRBG
129f4be
InitializeOncePerProcessInternal() calls CSPRNG(nullptr, 0) to confirm
OpenSSL's random source is seeded and installs a V8 entropy source that
goes through CSPRNG() as well. The first RAND_status() of the process
therefore runs before V8 starts, instantiates the DRBG, and with it
constructs the default provider's algorithm and name tables
(ossl_method_construct, ossl_namemap_stored): 3.7% of the samples of
`node -e 0` on Linux x64, all of it before v8Start.

V8 uses the entropy for hash seeds, address space layout randomization
and Math.random(), none of which are cryptographic, so read the OS
CSPRNG directly through uv_random(). AIX is the exception: uv_random()
reads the blocking /dev/random there, so it stays on OpenSSL's DRBG,
which seeds from /dev/urandom.

Keep activating the default provider at startup, which the eager check
did as a side effect and --openssl-legacy-provider depends on: its
explicit OSSL_PROVIDER_load() disables OpenSSL's provider fallback, so
without a prior activation the default provider never loads. Run the
seeding check itself only when that provider is unavailable or FIPS is
in effect, the cases where an OpenSSL configuration from any source
can leave the process without a DRBG and an early abort beats a hang
at the first crypto call. Every crypto consumer stays on OpenSSL, and
a system without a usable CSPRNG still aborts at startup, now from
uv_random() failing.

Measured on Linux x64 against an unpatched build of the same tree,
both binaries interleaved, min of 300 runs: `node -e 0` 29.18 ->
27.82 ms, nodeStart to v8Start 2.91 -> 2.11 ms. RAND_status and the
provider's table construction leave the startup profile (2.8% of
samples before); the provider activation that remains is 0.05%. The
first crypto.randomBytes() instantiates the DRBG in 0.19 ms. The `parallel`,
`sequential`, `message`, `es-module` and `addons` suites show no
failure the unpatched build does not have.

Refs: nodejs@5cc36c39d2
Refs: nodejs#44493
Refs: nodejs#46237
Signed-off-by: Colin McDonnell <[email protected]>
colinhacks added a commit to colinhacks/node that referenced this pull request Sep 4, 2026
@colinhacks
src: seed V8 from the OS CSPRNG instead of OpenSSL's DRBG
dea7e3d
InitializeOncePerProcessInternal() calls CSPRNG(nullptr, 0) to confirm
OpenSSL's random source is seeded and installs a V8 entropy source that
goes through CSPRNG() as well. The first RAND_status() of the process
therefore runs before V8 starts, instantiates the DRBG, and with it
constructs the default provider's algorithm and name tables
(ossl_method_construct, ossl_namemap_stored): 3.7% of the samples of
`node -e 0` on Linux x64, all of it before v8Start.

V8 uses the entropy for hash seeds, address space layout randomization
and Math.random(), none of which are cryptographic, so read the OS
CSPRNG directly through uv_random(). AIX is the exception: uv_random()
reads the blocking /dev/random there, so it stays on OpenSSL's DRBG,
which seeds from /dev/urandom.

Keep activating the default provider at startup, which the eager check
did as a side effect and --openssl-legacy-provider depends on: its
explicit OSSL_PROVIDER_load() disables OpenSSL's provider fallback, so
without a prior activation the default provider never loads. Run the
seeding check itself only when that provider is unavailable or FIPS is
in effect, the cases where an OpenSSL configuration from any source
can leave the process without a DRBG and an early abort beats a hang
at the first crypto call. Every crypto consumer stays on OpenSSL, and
a system without a usable CSPRNG still aborts at startup, now from
uv_random() failing.

Measured on Linux x64 against an unpatched build of the same tree,
both binaries interleaved, min of 300 runs: `node -e 0` 29.18 ->
27.82 ms, nodeStart to v8Start 2.91 -> 2.11 ms. RAND_status and the
provider's table construction leave the startup profile (2.8% of
samples before); the provider activation that remains is 0.05%. The
first crypto.randomBytes() instantiates the DRBG in 0.19 ms. The `parallel`,
`sequential`, `message`, `es-module` and `addons` suites show no
failure the unpatched build does not have.

Refs: nodejs@5cc36c39d2
Refs: nodejs#44493
Refs: nodejs#46237
Signed-off-by: Colin McDonnell <[email protected]>
colinhacks added a commit to colinhacks/node that referenced this pull request Sep 4, 2026
@colinhacks
src: seed V8 from the OS CSPRNG instead of OpenSSL's DRBG
1690e99
InitializeOncePerProcessInternal() calls CSPRNG(nullptr, 0) to confirm
OpenSSL's random source is seeded and installs a V8 entropy source that
goes through CSPRNG() as well. The first RAND_status() of the process
therefore runs before V8 starts, instantiates the DRBG, and with it
constructs the default provider's algorithm and name tables
(ossl_method_construct, ossl_namemap_stored): 3.7% of the samples of
`node -e 0` on Linux x64, all of it before v8Start.

V8 uses the entropy for hash seeds, address space layout randomization
and Math.random(), none of which are cryptographic, so read the OS
CSPRNG directly through uv_random(). AIX is the exception: uv_random()
reads the blocking /dev/random there, so it stays on OpenSSL's DRBG,
which seeds from /dev/urandom.

Keep activating the default provider at startup, which the eager check
did as a side effect and --openssl-legacy-provider depends on. Its
explicit OSSL_PROVIDER_load() disables OpenSSL's provider fallback, so
without a prior activation the default provider never loads. Run the
seeding check itself only when that provider is unavailable or FIPS is
in effect, the cases where an OpenSSL configuration from any source
can leave the process without a DRBG and an early abort beats a hang
at the first crypto call. Every crypto consumer stays on OpenSSL, and
a system without a usable CSPRNG still aborts at startup, now from
uv_random() failing.

Measured on Linux x64 against an unpatched build of the same tree,
both binaries interleaved, min of 300 runs: `node -e 0` 29.18 ->
27.82 ms, nodeStart to v8Start 2.91 -> 2.11 ms. RAND_status and the
provider's table construction leave the startup profile (2.8% of
samples before); the provider activation that remains is 0.05%. The
first crypto.randomBytes() instantiates the DRBG in 0.19 ms. The `parallel`,
`sequential`, `message`, `es-module` and `addons` suites show no
failure the unpatched build does not have.

Refs: nodejs@5cc36c39d2
Refs: nodejs#44493
Refs: nodejs#46237
Signed-off-by: Colin McDonnell <[email protected]>
colinhacks added a commit to colinhacks/node that referenced this pull request Sep 4, 2026
@colinhacks
src: seed V8 from the OS CSPRNG instead of OpenSSL's DRBG
4f28681
InitializeOncePerProcessInternal() calls CSPRNG(nullptr, 0) to confirm
OpenSSL's random source is seeded and installs a V8 entropy source that
goes through CSPRNG() as well. The first RAND_status() of the process
therefore runs before V8 starts, instantiates the DRBG, and with it
constructs the default provider's algorithm and name tables
(ossl_method_construct, ossl_namemap_stored): 3.7% of the samples of
`node -e 0` on Linux x64, all of it before v8Start.

V8 uses the entropy for hash seeds, address space layout randomization
and Math.random(), none of which are cryptographic, so read the OS
CSPRNG directly through uv_random(). AIX is the exception: uv_random()
reads the blocking /dev/random there, so it stays on OpenSSL's DRBG,
which seeds from /dev/urandom.

Keep activating the default provider at startup, which the eager check
did as a side effect and --openssl-legacy-provider depends on. Its
explicit OSSL_PROVIDER_load() disables OpenSSL's provider fallback, so
without a prior activation the default provider never loads. Run the
seeding check itself only when that provider is unavailable or FIPS is
in effect, the cases where an OpenSSL configuration from any source
can leave the process without a DRBG and an early abort beats a hang
at the first crypto call. Every crypto consumer stays on OpenSSL, and
a system without a usable CSPRNG still aborts at startup, now from
uv_random() failing.

Two other behaviors change. A configuration whose [random] section
names a DRBG that cannot be fetched used to abort at startup; it now
starts and the first crypto call fails on the fetch. With --secure-heap
the process DRBGs are instantiated after the secure heap exists, so
they are allocated from it, and a Worker whose per-thread DRBG cannot
be allocated no longer aborts the process from the entropy callback.
Tests cover both, and the default provider staying active under
--openssl-legacy-provider.

Measured on Linux x64 against an unpatched build of the same tree,
both binaries interleaved, min of 300 runs: `node -e 0` 29.18 ->
27.82 ms, nodeStart to v8Start 2.91 -> 2.11 ms. RAND_status and the
provider's table construction leave the startup profile (2.8% of
samples before); the provider activation that remains is 0.05%. The
first crypto.randomBytes() instantiates the DRBG in 0.19 ms. The `parallel`,
`sequential`, `message`, `es-module` and `addons` suites show no
failure the unpatched build does not have.

Refs: nodejs@5cc36c39d2
Refs: nodejs#44493
Refs: nodejs#46237
Signed-off-by: Colin McDonnell <[email protected]>
colinhacks added a commit to colinhacks/node that referenced this pull request Sep 4, 2026
@colinhacks
src: seed V8 from the OS CSPRNG instead of OpenSSL's DRBG
ced7dc9
InitializeOncePerProcessInternal() calls CSPRNG(nullptr, 0) to confirm
OpenSSL's random source is seeded and installs a V8 entropy source that
goes through CSPRNG() as well. The first RAND_status() of the process
therefore runs before V8 starts, instantiates the DRBG, and with it
constructs the default provider's algorithm and name tables
(ossl_method_construct, ossl_namemap_stored): 3.7% of the samples of
`node -e 0` on Linux x64, all of it before v8Start.

V8 uses the entropy for hash seeds, address space layout randomization
and Math.random(), none of which are cryptographic, so read the OS
CSPRNG directly through uv_random(). AIX is the exception: uv_random()
reads the blocking /dev/random there, so it stays on OpenSSL's DRBG,
which seeds from /dev/urandom.

Keep activating the default provider at startup, which the eager check
did as a side effect and --openssl-legacy-provider depends on. Its
explicit OSSL_PROVIDER_load() disables OpenSSL's provider fallback, so
without a prior activation the default provider never loads. Run the
seeding check itself only when that provider is unavailable or FIPS is
in effect, the cases where an OpenSSL configuration from any source
can leave the process without a DRBG and an early abort beats a hang
at the first crypto call. Every crypto consumer stays on OpenSSL, and
a system without a usable CSPRNG still aborts at startup, now from
uv_random() failing.

Two other behaviors change. A configuration whose [random] section
names a DRBG that cannot be fetched used to abort at startup; it now
starts and the first crypto call fails on the fetch. With --secure-heap
the process DRBGs are instantiated after the secure heap exists, so
they are allocated from it, and a Worker whose per-thread DRBG cannot
be allocated no longer aborts the process from the entropy callback.
Tests cover both, and the default provider staying active under
--openssl-legacy-provider.

Measured on Linux x64 against an unpatched build of the same tree,
both binaries interleaved, min of 300 runs: `node -e 0` 29.18 ->
27.82 ms, nodeStart to v8Start 2.91 -> 2.11 ms. RAND_status and the
provider's table construction leave the startup profile (2.8% of
samples before); the provider activation that remains is 0.05%. The
first crypto.randomBytes() instantiates the DRBG in 0.19 ms. The
`parallel`, `sequential`, `message`, `es-module` and `addons` suites
show no failure the unpatched build does not have.

Refs: nodejs@5cc36c39d2
Refs: nodejs#44493
Refs: nodejs#46237
Signed-off-by: Colin McDonnell <[email protected]>
colinhacks added a commit to colinhacks/node that referenced this pull request Sep 4, 2026
@colinhacks
src: seed V8 from the OS CSPRNG instead of OpenSSL's DRBG
650888d
InitializeOncePerProcessInternal() calls CSPRNG(nullptr, 0) to confirm
OpenSSL's random source is seeded and installs a V8 entropy source that
goes through CSPRNG() as well. The first RAND_status() of the process
therefore runs before V8 starts, instantiates the DRBG, and with it
constructs the default provider's algorithm and name tables
(ossl_method_construct, ossl_namemap_stored): 3.7% of the samples of
`node -e 0` on Linux x64, all of it before v8Start.

V8 uses the entropy for hash seeds, address space layout randomization
and Math.random(), none of which are cryptographic, so read the OS
CSPRNG directly through uv_random(). AIX is the exception: uv_random()
reads the blocking /dev/random there, so it stays on OpenSSL's DRBG,
which seeds from /dev/urandom.

Keep activating the default provider at startup, which the eager check
did as a side effect and --openssl-legacy-provider depends on. Its
explicit OSSL_PROVIDER_load() disables OpenSSL's provider fallback, so
without a prior activation the default provider never loads. Run the
seeding check itself only when that provider is unavailable or FIPS is
in effect, the cases where an OpenSSL configuration from any source
can leave the process without a DRBG and an early abort beats a hang
at the first crypto call. Every crypto consumer stays on OpenSSL, and
a system without a usable CSPRNG still aborts at startup, now from
uv_random() failing.

Two other behaviors change. A configuration whose [random] section
names a DRBG that cannot be fetched used to abort at startup; it now
starts and the first crypto call fails on the fetch. With --secure-heap
the process DRBGs are instantiated after the secure heap exists, so
they are allocated from it, and a Worker whose per-thread DRBG cannot
be allocated no longer aborts the process from the entropy callback.
Tests cover both, and the default provider staying active under
--openssl-legacy-provider.

Measured on Linux x64 against an unpatched build of the same tree,
both binaries interleaved, min of 300 runs: `node -e 0` 29.18 ->
27.82 ms, nodeStart to v8Start 2.91 -> 2.11 ms. RAND_status and the
provider's table construction leave the startup profile (2.8% of
samples before); the provider activation that remains is 0.05%. The
first crypto.randomBytes() instantiates the DRBG in 0.19 ms. The
`parallel`, `sequential`, `message`, `es-module` and `addons` suites
show no failure the unpatched build does not have.

Refs: nodejs@5cc36c39d2
Refs: nodejs#44493
Refs: nodejs#46237
Signed-off-by: Colin McDonnell <[email protected]>
colinhacks added a commit to colinhacks/node that referenced this pull request Sep 8, 2026
@colinhacks
src: seed V8 from the OS CSPRNG instead of OpenSSL's DRBG
c8c9d26
InitializeOncePerProcessInternal() calls CSPRNG(nullptr, 0) to confirm
OpenSSL's random source is seeded and installs a V8 entropy source that
goes through CSPRNG() as well. The first RAND_status() of the process
therefore runs before V8 starts, instantiates the DRBG, and with it
constructs the default provider's algorithm and name tables
(ossl_method_construct, ossl_namemap_stored): 3.7% of the samples of
`node -e 0` on Linux x64, all of it before v8Start.

V8 uses the entropy for hash seeds, address space layout randomization
and Math.random(), none of which are cryptographic, so read the OS
CSPRNG directly through uv_random(). AIX is the exception: uv_random()
reads the blocking /dev/random there, so it stays on OpenSSL's DRBG,
which seeds from /dev/urandom.

Keep activating the default provider at startup, which the eager check
did as a side effect and --openssl-legacy-provider depends on. Its
explicit OSSL_PROVIDER_load() disables OpenSSL's provider fallback, so
without a prior activation the default provider never loads. Run the
seeding check itself only when that provider is unavailable or FIPS is
in effect, the cases where an OpenSSL configuration from any source
can leave the process without a DRBG and an early abort beats a hang
at the first crypto call. Every crypto consumer stays on OpenSSL, and
a system without a usable CSPRNG still aborts at startup, now from
uv_random() failing.

Two other behaviors change. A configuration whose [random] section
names a DRBG that cannot be fetched used to abort at startup; it now
starts and the first crypto call fails on the fetch. With --secure-heap
the process DRBGs are instantiated after the secure heap exists, so
they are allocated from it, and a Worker whose per-thread DRBG cannot
be allocated no longer aborts the process from the entropy callback.
Tests cover both, and the default provider staying active under
--openssl-legacy-provider.

Measured on Linux x64 against an unpatched build of the same tree,
both binaries interleaved, min of 300 runs: `node -e 0` 29.18 ->
27.82 ms, nodeStart to v8Start 2.91 -> 2.11 ms. RAND_status and the
provider's table construction leave the startup profile (2.8% of
samples before); the provider activation that remains is 0.05%. The
first crypto.randomBytes() instantiates the DRBG in 0.19 ms. The
`parallel`, `sequential`, `message`, `es-module` and `addons` suites
show no failure the unpatched build does not have.

Refs: nodejs@5cc36c39d2
Refs: nodejs#44493
Refs: nodejs#46237
Signed-off-by: Colin McDonnell <[email protected]>
colinhacks added a commit to colinhacks/node that referenced this pull request Sep 8, 2026
@colinhacks
src: seed V8 from the OS CSPRNG instead of OpenSSL's DRBG
f028cad
InitializeOncePerProcessInternal() calls CSPRNG(nullptr, 0) to confirm
OpenSSL's random source is seeded and installs a V8 entropy source that
goes through CSPRNG() as well. The first RAND_status() of the process
therefore runs before V8 starts, instantiates the DRBG, and with it
constructs the default provider's algorithm and name tables
(ossl_method_construct, ossl_namemap_stored): 3.7% of the samples of
`node -e 0` on Linux x64, all of it before v8Start.

V8 uses the entropy for hash seeds, address space layout randomization
and Math.random(), none of which are cryptographic, so read the OS
CSPRNG directly through uv_random(). AIX is the exception: uv_random()
reads the blocking /dev/random there, so it stays on OpenSSL's DRBG,
which seeds from /dev/urandom.

Keep activating the default provider at startup, which the eager check
did as a side effect and --openssl-legacy-provider depends on. Its
explicit OSSL_PROVIDER_load() disables OpenSSL's provider fallback, so
without a prior activation the default provider never loads. Run the
seeding check itself only when that provider is unavailable or FIPS is
in effect, the cases where an OpenSSL configuration from any source
can leave the process without a DRBG and an early abort beats a hang
at the first crypto call. Every crypto consumer stays on OpenSSL, and
a system without a usable CSPRNG still aborts at startup, now from
uv_random() failing.

Two other behaviors change. A configuration whose [random] section
names a DRBG that cannot be fetched used to abort at startup; it now
starts and the first crypto call fails on the fetch. With --secure-heap
the process DRBGs are instantiated after the secure heap exists, so
they are allocated from it, and a Worker's isolate setup no longer
aborts the process from the entropy callback when the heap cannot hold
another per-thread DRBG. Tests cover both, and the default provider
staying active under --openssl-legacy-provider.

Measured on Linux x64 against an unpatched build of the same tree,
both binaries interleaved, min of 300 runs: `node -e 0` 29.18 ->
27.82 ms, nodeStart to v8Start 2.91 -> 2.11 ms. RAND_status and the
provider's table construction leave the startup profile (2.8% of
samples before); the provider activation that remains is 0.05%. The
first crypto.randomBytes() instantiates the DRBG in 0.19 ms. The
`parallel`, `sequential`, `message`, `es-module` and `addons` suites
show no failure the unpatched build does not have.

Refs: nodejs@5cc36c39d2
Refs: nodejs#44493
Refs: nodejs#46237
Signed-off-by: Colin McDonnell <[email protected]>
nodejs-github-bot pushed a commit that referenced this pull request Sep 10, 2026
@colinhacks
src: seed V8 from the OS CSPRNG instead of OpenSSL's DRBG
43d3fe9
InitializeOncePerProcessInternal() calls CSPRNG(nullptr, 0) to confirm
OpenSSL's random source is seeded and installs a V8 entropy source that
goes through CSPRNG() as well. The first RAND_status() of the process
therefore runs before V8 starts, instantiates the DRBG, and with it
constructs the default provider's algorithm and name tables
(ossl_method_construct, ossl_namemap_stored): 3.7% of the samples of
`node -e 0` on Linux x64, all of it before v8Start.

V8 uses the entropy for hash seeds, address space layout randomization
and Math.random(), none of which are cryptographic, so read the OS
CSPRNG directly through uv_random(). AIX is the exception: uv_random()
reads the blocking /dev/random there, so it stays on OpenSSL's DRBG,
which seeds from /dev/urandom.

Keep activating the default provider at startup, which the eager check
did as a side effect and --openssl-legacy-provider depends on. Its
explicit OSSL_PROVIDER_load() disables OpenSSL's provider fallback, so
without a prior activation the default provider never loads. Run the
seeding check itself only when that provider is unavailable or FIPS is
in effect, the cases where an OpenSSL configuration from any source
can leave the process without a DRBG and an early abort beats a hang
at the first crypto call. Every crypto consumer stays on OpenSSL, and
a system without a usable CSPRNG still aborts at startup, now from
uv_random() failing.

Two other behaviors change. A configuration whose [random] section
names a DRBG that cannot be fetched used to abort at startup; it now
starts and the first crypto call fails on the fetch. With --secure-heap
the process DRBGs are instantiated after the secure heap exists, so
they are allocated from it, and a Worker's isolate setup no longer
aborts the process from the entropy callback when the heap cannot hold
another per-thread DRBG. Tests cover both, and the default provider
staying active under --openssl-legacy-provider.

Measured on Linux x64 against an unpatched build of the same tree,
both binaries interleaved, min of 300 runs: `node -e 0` 29.18 ->
27.82 ms, nodeStart to v8Start 2.91 -> 2.11 ms. RAND_status and the
provider's table construction leave the startup profile (2.8% of
samples before); the provider activation that remains is 0.05%. The
first crypto.randomBytes() instantiates the DRBG in 0.19 ms. The
`parallel`, `sequential`, `message`, `es-module` and `addons` suites
show no failure the unpatched build does not have.

Refs: 5cc36c39d2
Refs: #44493
Refs: #46237
Signed-off-by: Colin McDonnell <[email protected]>
PR-URL: #65796
Reviewed-By: Filip Skokan <[email protected]>
Reviewed-By: James M Snell <[email protected]>
aduh95 pushed a commit that referenced this pull request Sep 16, 2026
@colinhacks @aduh95
src: seed V8 from the OS CSPRNG instead of OpenSSL's DRBG
f245e53
InitializeOncePerProcessInternal() calls CSPRNG(nullptr, 0) to confirm
OpenSSL's random source is seeded and installs a V8 entropy source that
goes through CSPRNG() as well. The first RAND_status() of the process
therefore runs before V8 starts, instantiates the DRBG, and with it
constructs the default provider's algorithm and name tables
(ossl_method_construct, ossl_namemap_stored): 3.7% of the samples of
`node -e 0` on Linux x64, all of it before v8Start.

V8 uses the entropy for hash seeds, address space layout randomization
and Math.random(), none of which are cryptographic, so read the OS
CSPRNG directly through uv_random(). AIX is the exception: uv_random()
reads the blocking /dev/random there, so it stays on OpenSSL's DRBG,
which seeds from /dev/urandom.

Keep activating the default provider at startup, which the eager check
did as a side effect and --openssl-legacy-provider depends on. Its
explicit OSSL_PROVIDER_load() disables OpenSSL's provider fallback, so
without a prior activation the default provider never loads. Run the
seeding check itself only when that provider is unavailable or FIPS is
in effect, the cases where an OpenSSL configuration from any source
can leave the process without a DRBG and an early abort beats a hang
at the first crypto call. Every crypto consumer stays on OpenSSL, and
a system without a usable CSPRNG still aborts at startup, now from
uv_random() failing.

Two other behaviors change. A configuration whose [random] section
names a DRBG that cannot be fetched used to abort at startup; it now
starts and the first crypto call fails on the fetch. With --secure-heap
the process DRBGs are instantiated after the secure heap exists, so
they are allocated from it, and a Worker's isolate setup no longer
aborts the process from the entropy callback when the heap cannot hold
another per-thread DRBG. Tests cover both, and the default provider
staying active under --openssl-legacy-provider.

Measured on Linux x64 against an unpatched build of the same tree,
both binaries interleaved, min of 300 runs: `node -e 0` 29.18 ->
27.82 ms, nodeStart to v8Start 2.91 -> 2.11 ms. RAND_status and the
provider's table construction leave the startup profile (2.8% of
samples before); the provider activation that remains is 0.05%. The
first crypto.randomBytes() instantiates the DRBG in 0.19 ms. The
`parallel`, `sequential`, `message`, `es-module` and `addons` suites
show no failure the unpatched build does not have.

Refs: 5cc36c39d2
Refs: #44493
Refs: #46237
Signed-off-by: Colin McDonnell <[email protected]>
PR-URL: #65796
Reviewed-By: Filip Skokan <[email protected]>
Reviewed-By: James M Snell <[email protected]>
aduh95 pushed a commit that referenced this pull request Sep 22, 2026
@colinhacks @aduh95
src: seed V8 from the OS CSPRNG instead of OpenSSL's DRBG
dcaded9
InitializeOncePerProcessInternal() calls CSPRNG(nullptr, 0) to confirm
OpenSSL's random source is seeded and installs a V8 entropy source that
goes through CSPRNG() as well. The first RAND_status() of the process
therefore runs before V8 starts, instantiates the DRBG, and with it
constructs the default provider's algorithm and name tables
(ossl_method_construct, ossl_namemap_stored): 3.7% of the samples of
`node -e 0` on Linux x64, all of it before v8Start.

V8 uses the entropy for hash seeds, address space layout randomization
and Math.random(), none of which are cryptographic, so read the OS
CSPRNG directly through uv_random(). AIX is the exception: uv_random()
reads the blocking /dev/random there, so it stays on OpenSSL's DRBG,
which seeds from /dev/urandom.

Keep activating the default provider at startup, which the eager check
did as a side effect and --openssl-legacy-provider depends on. Its
explicit OSSL_PROVIDER_load() disables OpenSSL's provider fallback, so
without a prior activation the default provider never loads. Run the
seeding check itself only when that provider is unavailable or FIPS is
in effect, the cases where an OpenSSL configuration from any source
can leave the process without a DRBG and an early abort beats a hang
at the first crypto call. Every crypto consumer stays on OpenSSL, and
a system without a usable CSPRNG still aborts at startup, now from
uv_random() failing.

Two other behaviors change. A configuration whose [random] section
names a DRBG that cannot be fetched used to abort at startup; it now
starts and the first crypto call fails on the fetch. With --secure-heap
the process DRBGs are instantiated after the secure heap exists, so
they are allocated from it, and a Worker's isolate setup no longer
aborts the process from the entropy callback when the heap cannot hold
another per-thread DRBG. Tests cover both, and the default provider
staying active under --openssl-legacy-provider.

Measured on Linux x64 against an unpatched build of the same tree,
both binaries interleaved, min of 300 runs: `node -e 0` 29.18 ->
27.82 ms, nodeStart to v8Start 2.91 -> 2.11 ms. RAND_status and the
provider's table construction leave the startup profile (2.8% of
samples before); the provider activation that remains is 0.05%. The
first crypto.randomBytes() instantiates the DRBG in 0.19 ms. The
`parallel`, `sequential`, `message`, `es-module` and `addons` suites
show no failure the unpatched build does not have.

Refs: 5cc36c39d2
Refs: #44493
Refs: #46237
Signed-off-by: Colin McDonnell <[email protected]>
PR-URL: #65796
Reviewed-By: Filip Skokan <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@bnoordhuis bnoordhuis bnoordhuis approved these changes
@addaleax addaleax addaleax approved these changes

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

author ready PRs with CI started, the required approvals, and no outstanding review comments. c++ Issues and PRs that require attention from people who are familiar with C++. commit-queue-squash PRs the Commit Queue should land as one squashed commit. crypto Issues and PRs related to the crypto subsystem. needs-ci PRs that need a full CI run.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Enabling FIPS mode on plain Ubuntu 22.04 and using crypto leads to infinite hang in CSPRNG

Uh oh!

There was an error while loading. Please reload this page.

6 participants

@richardlau @nodejs-github-bot @bnoordhuis @addaleax @lpinca @targos
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.