Skip to content

crypto,build: require OpenSSL 3, remove runtime FIPS API - #64777

Draft
panva wants to merge 9 commits into
nodejs:mainfrom
panva:drop-openssl1
Draft

crypto,build: require OpenSSL 3, remove runtime FIPS API#64777
panva wants to merge 9 commits into
nodejs:mainfrom
panva:drop-openssl1

Conversation

@panva

@panva panva commented Jul 27, 2026

Copy link
Copy Markdown
Member

Important

Prior to marking this ready for review, or more specifically, running a full CI, a change similar to https://github.com/nodejs/build/pull/4386/changes needs to land to exclude OpenSSL 1.1.1 builds for gte(27) (nodejs/build#4409).

This will hang around as draft for comments until we get to v27.x alphas

Drops support for building or linking against OpenSSL 1.x, and with it the FIPS features that either never worked or no longer mean what they claim under the provider model. #64211 split the native crypto backends so that this could be a focused follow-up.

configure now fails when --shared-openssl points at anything older than 3.0.0, instead of failing later at compile or link time. crypto.setFips(), crypto.fips and --force-fips are removed, and --openssl-is-fips now requires --shared-openssl, since with the bundled OpenSSL it no longer has anything to configure. crypto.getFips() and --enable-fips are retained, as is BoringSSL support.

Under the provider model "FIPS mode" only narrows the default property query to fips=yes; it does not load, activate or validate a FIPS provider. So crypto.setFips(true) succeeded even with no provider present, leaving crypto.getFips() reporting 1 while every operation failed with ERR_OSSL_EVP_UNSUPPORTED, and crypto.setFips(false) threw Error: Ok while succeeding. --force-fips existed only to lock the setter out. --enable-fips still refuses to start without an active fips provider, and now says why rather than printing an empty OpenSSL error.

--openssl-is-fips against the bundled OpenSSL never worked either: openssl-fipsmodule has no dependency edge from node.gyp, so gyp emitted no rules for it and fipsinstall's input was produced by nothing. Repairing it would not help, since a provider built out of the Node.js tree has no validation status regardless.

BoringSSL reports itself as OpenSSL 1.1.1, so every version check was also excluding it and the legacy branches are live BoringSSL code rather than dead 1.x code. Most are rewritten to check OPENSSL_IS_BORINGSSL now. ENGINE support is untouched and stays on its own removal track (#63966).

Fixes: #56733
Refs: #64211
Refs: #48950
Refs: #55937
Refs: #59069
Refs: #50542
Refs: #46200
Refs: #60270
Refs: #45465
Refs: #48776
Refs: #42827
Refs: #47076
Refs: #62982
Refs: #62862
Refs: #38512

@panva
panva requested a review from richardlau July 27, 2026 11:01
@panva panva added the semver-major PRs that contain breaking changes and should be released in the next major version. label Jul 27, 2026
@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

Review requested:

  • @nodejs/actions
  • @nodejs/build
  • @nodejs/config
  • @nodejs/crypto
  • @nodejs/gyp
  • @nodejs/security-wg
  • @nodejs/startup
  • @nodejs/tsc
  • @nodejs/userland-migrations

@nodejs-github-bot nodejs-github-bot added lib / src Issues and PRs related to general changes in the lib or src directory. needs-ci PRs that need a full CI run. labels Jul 27, 2026
@panva panva added the commit-queue-rebase Add this label to allow the Commit Queue to land a PR in several commits. label Jul 27, 2026
@panva
panva removed the request for review from richardlau July 27, 2026 11:04
@panva panva added crypto Issues and PRs related to the crypto subsystem. tls Issues and PRs related to the tls subsystem. labels Jul 27, 2026
panva added 5 commits July 27, 2026 13:12
configure now fails when --shared-openssl points at OpenSSL 1.x, and
the CI matrix no longer builds against it. BoringSSL reports itself as
OpenSSL 1.1.1, so it is exempt.

Signed-off-by: Filip Skokan <panva.ip@gmail.com>
Remove the OpenSSL 1.x backend. Version guards become
OPENSSL_IS_BORINGSSL checks rather than being deleted, because
BoringSSL reports itself as OpenSSL 1.1.1 and relies on those branches.

Signed-off-by: Filip Skokan <panva.ip@gmail.com>
Remove the OpenSSL 1.x branches from src/. The remaining version guards
become OPENSSL_IS_BORINGSSL checks, since BoringSSL reports itself as
OpenSSL 1.1.1 and their else branches are its own.

Signed-off-by: Filip Skokan <panva.ip@gmail.com>
Delete test-crypto-ecb.js, which can no longer run anywhere: Blowfish
is legacy-provider only on OpenSSL 3 and absent from BoringSSL.

The addon and cctest version guards become OPENSSL_IS_BORINGSSL checks.

Signed-off-by: Filip Skokan <panva.ip@gmail.com>
Rename the openssl30 footnote to say what it now means, and refresh the
stale man1.1.1 links.

Signed-off-by: Filip Skokan <panva.ip@gmail.com>
panva added 4 commits July 27, 2026 13:31
crypto.setFips() only narrowed OpenSSL's default property query: it
succeeded with no FIPS provider present, and setFips(false) threw
"Error: Ok" while working.

Remove crypto.setFips(), crypto.fips and --force-fips. crypto.getFips()
and --enable-fips are retained.

Signed-off-by: Filip Skokan <panva.ip@gmail.com>
The startup failure always appended the OpenSSL error queue, so when
Node.js itself detected the missing fips provider it printed an error
header followed by nothing. Report the reason instead.

Signed-off-by: Filip Skokan <panva.ip@gmail.com>
The openssl_fips_*.cnf fixtures use OpenSSL 1.x syntax and are unused,
get_env_type() sniffed for a "-fips" version suffix that can no longer
occur, and the crypto-check lint rule listed a helper that no longer
exists.

Signed-off-by: Filip Skokan <panva.ip@gmail.com>
--openssl-is-fips with bundled OpenSSL never worked: the
openssl-fipsmodule target had no dependency edge, so fipsinstall's
input was produced by nothing. Repairing it would not help, since a
FIPS provider built out of tree has no validation status.

Remove the machinery and restrict --openssl-is-fips to --shared-openssl.

Signed-off-by: Filip Skokan <panva.ip@gmail.com>
@Renegade334

Copy link
Copy Markdown
Member

Even though it doesn't work as advertised, should we be adding a deprecation for the FIPS accessors for existing release lines as a warning shot, or indeed doc-deprecating in LTS lines and then an accelerated runtime deprecation for v26.x?

@panva

panva commented Jul 27, 2026

Copy link
Copy Markdown
Member Author

Even though it doesn't work as advertised, should we be adding a deprecation for the FIPS accessors for existing release lines as a warning shot, or indeed doc-deprecating in LTS lines and then an accelerated runtime deprecation for v26.x?

The APIs and CLI options are broken with the provider model already, they only work as advertised when 1.1.1 is used and i'm not sure what the state of OpenSSL 1 FIPS module use is. I don't see the point in disturbing the older release lines for those rare cases where it works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

commit-queue-rebase Add this label to allow the Commit Queue to land a PR in several commits. crypto Issues and PRs related to the crypto subsystem. lib / src Issues and PRs related to general changes in the lib or src directory. needs-ci PRs that need a full CI run. semver-major PRs that contain breaking changes and should be released in the next major version. tls Issues and PRs related to the tls subsystem.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Question around dropping support for OpenSSL < 3

3 participants