crypto: evict getCiphers/getHashes cache on setFips/setEngine

[srikanth-karthi]

Fixes: #62982

Summary

getCiphers() and getHashes() used cachedResult() which memoizes on first call and never clears. Two operations mutate the OpenSSL algorithm set but did not invalidate the cache:

• setFips(true/false) — restricts/restores the visible cipher/hash list to FIPS-approved algorithms only
• setEngine(id, flags) — loads an OpenSSL engine that may register additional ciphers/hashes

This meant that after calling either function, getCiphers() and getHashes() would continue returning the stale pre-call snapshot.

Changes

• Replace the two cachedResult() calls for getCiphers/getHashes in lib/internal/crypto/util.js with manual let _ciphersCache / let _hashesCache variables — mirroring the existing _hashCache / getHashCache() pattern already in the same file.
• Add evictCipherHashCache() that resets both variables to undefined.
• Call evictCipherHashCache() from setEngine() (after a successful engine load) and from setFips() (after setFipsCrypto(val)).
• getCurves intentionally keeps using cachedResult() — curves are not affected by FIPS mode or engine loading.

[nodejs-github-bot]

Review requested:

• @nodejs/crypto

[panva]

@srikanth-karthi thank you, this looks good on first a cursory look but can you add a test? we do have fips enabled runners in CI that could use one.

[ChALkeR]

As #62982 details mention: under BoringSSL, internal code in conditionalAlgorithms calls getHashes and getCiphers at load.

node/lib/internal/crypto/util.js

Lines 405 to 410 in bb85d23

	'ChaCha20-Poly1305': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getCiphers(),'chacha20-poly1305'),
	'cSHAKE128': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getHashes(),'shake128'),
	'cSHAKE256': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getHashes(),'shake256'),

Those results are also stale

[panva]

BoringSSL has no fips mode. And when it's not boringssl and the ciphers "become unavailable" due to a toggle switch they'll start failing with OperationError and the only inconsistency will be SubtleCrypto.supports reporting true when it should be false.

The "fips to non-fips" case 🤷

Imho not worth the churn.

[srikanth-karthi]

Thanks for the context. Agreed — under BoringSSL there's no FIPS mode so conditionalAlgorithms is stable for the process lifetime, and for OpenSSL the SubtleCrypto.supports() inconsistency after a FIPS toggle is an accepted limitation given the churn required to fix it. I'll leave conditionalAlgorithms out of scope for this PR.

[panva]

@ChALkeR what do you think about keeping the identity of the cached result the same? that way consumer can actually rely on their returned value and not get tripped up by someone elses' concern flipping fips mode.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.66%. Comparing base (85ae4cd) to head (76e61cb).
⚠️ Report is 1085 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #62985 +/- ##
=======================================
Coverage 89.66% 89.66% =======================================
Files 707 707 Lines 219501 219523 +22 Branches 42087 42092 +5 =======================================
+ Hits 196807 196832 +25 
Misses 14588 14588 + Partials 8106 8103 -3 

Files with missing lines	Coverage Δ
lib/crypto.js	93.04% <100.00%> (+0.81%)	⬆️
lib/internal/crypto/util.js	95.89% <100.00%> (+0.09%)	⬆️

... and 28 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

This pull request has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

[panva]

setFips() invalidation is superseded by #65484, I don't believe dealing with setEngine()-triggered invalidation is worth the churn since engines are on the way out of the codebase (#63966, #64777 (comment)).

[srikanth-karthi]

Fixes: #62982

Summary

getCiphers() and getHashes() used cachedResult() which memoizes on first call and never clears. Two operations mutate the OpenSSL algorithm set but did not invalidate the cache:

• setFips(true/false) — restricts/restores the visible cipher/hash list to FIPS-approved algorithms only
• setEngine(id, flags) — loads an OpenSSL engine that may register additional ciphers/hashes

This meant that after calling either function, getCiphers() and getHashes() would continue returning the stale pre-call snapshot.

Changes

• Replace the two cachedResult() calls for getCiphers/getHashes in lib/internal/crypto/util.js with manual let _ciphersCache / let _hashesCache variables — mirroring the existing _hashCache / getHashCache() pattern already in the same file.
• Add evictCipherHashCache() that resets both variables to undefined.
• Call evictCipherHashCache() from setEngine() (after a successful engine load) and from setFips() (after setFipsCrypto(val)).
• getCurves intentionally keeps using cachedResult() — curves are not affected by FIPS mode or engine loading.

[nodejs-github-bot]

Review requested:

• @nodejs/crypto

[panva]

@srikanth-karthi thank you, this looks good on first a cursory look but can you add a test? we do have fips enabled runners in CI that could use one.

[ChALkeR]

As #62982 details mention: under BoringSSL, internal code in conditionalAlgorithms calls getHashes and getCiphers at load.

node/lib/internal/crypto/util.js

Lines 405 to 410 in bb85d23

	'ChaCha20-Poly1305': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getCiphers(),'chacha20-poly1305'),
	'cSHAKE128': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getHashes(),'shake128'),
	'cSHAKE256': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getHashes(),'shake256'),

Those results are also stale

[panva]

BoringSSL has no fips mode. And when it's not boringssl and the ciphers "become unavailable" due to a toggle switch they'll start failing with OperationError and the only inconsistency will be SubtleCrypto.supports reporting true when it should be false.

The "fips to non-fips" case 🤷

Imho not worth the churn.

[srikanth-karthi]

Thanks for the context. Agreed — under BoringSSL there's no FIPS mode so conditionalAlgorithms is stable for the process lifetime, and for OpenSSL the SubtleCrypto.supports() inconsistency after a FIPS toggle is an accepted limitation given the churn required to fix it. I'll leave conditionalAlgorithms out of scope for this PR.

[panva]

@ChALkeR what do you think about keeping the identity of the cached result the same? that way consumer can actually rely on their returned value and not get tripped up by someone elses' concern flipping fips mode.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.66%. Comparing base (85ae4cd) to head (76e61cb).
⚠️ Report is 1085 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #62985 +/- ##
=======================================
Coverage 89.66% 89.66% =======================================
Files 707 707 Lines 219501 219523 +22 Branches 42087 42092 +5 =======================================
+ Hits 196807 196832 +25 
Misses 14588 14588 + Partials 8106 8103 -3 

Files with missing lines	Coverage Δ
lib/crypto.js	93.04% <100.00%> (+0.81%)	⬆️
lib/internal/crypto/util.js	95.89% <100.00%> (+0.09%)	⬆️

... and 28 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

This pull request has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

[panva]

setFips() invalidation is superseded by #65484, I don't believe dealing with setEngine()-triggered invalidation is worth the churn since engines are on the way out of the codebase (#63966, #64777 (comment)).

[srikanth-karthi]

Fixes: #62982

Summary

getCiphers() and getHashes() used cachedResult() which memoizes on first call and never clears. Two operations mutate the OpenSSL algorithm set but did not invalidate the cache:

• setFips(true/false) — restricts/restores the visible cipher/hash list to FIPS-approved algorithms only
• setEngine(id, flags) — loads an OpenSSL engine that may register additional ciphers/hashes

This meant that after calling either function, getCiphers() and getHashes() would continue returning the stale pre-call snapshot.

Changes

• Replace the two cachedResult() calls for getCiphers/getHashes in lib/internal/crypto/util.js with manual let _ciphersCache / let _hashesCache variables — mirroring the existing _hashCache / getHashCache() pattern already in the same file.
• Add evictCipherHashCache() that resets both variables to undefined.
• Call evictCipherHashCache() from setEngine() (after a successful engine load) and from setFips() (after setFipsCrypto(val)).
• getCurves intentionally keeps using cachedResult() — curves are not affected by FIPS mode or engine loading.

[nodejs-github-bot]

Review requested:

• @nodejs/crypto

[panva]

@srikanth-karthi thank you, this looks good on first a cursory look but can you add a test? we do have fips enabled runners in CI that could use one.

[ChALkeR]

As #62982 details mention: under BoringSSL, internal code in conditionalAlgorithms calls getHashes and getCiphers at load.

node/lib/internal/crypto/util.js

Lines 405 to 410 in bb85d23

	'ChaCha20-Poly1305': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getCiphers(),'chacha20-poly1305'),
	'cSHAKE128': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getHashes(),'shake128'),
	'cSHAKE256': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getHashes(),'shake256'),

Those results are also stale

[panva]

BoringSSL has no fips mode. And when it's not boringssl and the ciphers "become unavailable" due to a toggle switch they'll start failing with OperationError and the only inconsistency will be SubtleCrypto.supports reporting true when it should be false.

The "fips to non-fips" case 🤷

Imho not worth the churn.

[srikanth-karthi]

Thanks for the context. Agreed — under BoringSSL there's no FIPS mode so conditionalAlgorithms is stable for the process lifetime, and for OpenSSL the SubtleCrypto.supports() inconsistency after a FIPS toggle is an accepted limitation given the churn required to fix it. I'll leave conditionalAlgorithms out of scope for this PR.

[panva]

@ChALkeR what do you think about keeping the identity of the cached result the same? that way consumer can actually rely on their returned value and not get tripped up by someone elses' concern flipping fips mode.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.66%. Comparing base (85ae4cd) to head (76e61cb).
⚠️ Report is 1085 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #62985 +/- ##
=======================================
Coverage 89.66% 89.66% =======================================
Files 707 707 Lines 219501 219523 +22 Branches 42087 42092 +5 =======================================
+ Hits 196807 196832 +25 
Misses 14588 14588 + Partials 8106 8103 -3 

Files with missing lines	Coverage Δ
lib/crypto.js	93.04% <100.00%> (+0.81%)	⬆️
lib/internal/crypto/util.js	95.89% <100.00%> (+0.09%)	⬆️

... and 28 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

This pull request has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

[panva]

setFips() invalidation is superseded by #65484, I don't believe dealing with setEngine()-triggered invalidation is worth the churn since engines are on the way out of the codebase (#63966, #64777 (comment)).

[srikanth-karthi]

Fixes: #62982

Summary

getCiphers() and getHashes() used cachedResult() which memoizes on first call and never clears. Two operations mutate the OpenSSL algorithm set but did not invalidate the cache:

• setFips(true/false) — restricts/restores the visible cipher/hash list to FIPS-approved algorithms only
• setEngine(id, flags) — loads an OpenSSL engine that may register additional ciphers/hashes

This meant that after calling either function, getCiphers() and getHashes() would continue returning the stale pre-call snapshot.

Changes

• Replace the two cachedResult() calls for getCiphers/getHashes in lib/internal/crypto/util.js with manual let _ciphersCache / let _hashesCache variables — mirroring the existing _hashCache / getHashCache() pattern already in the same file.
• Add evictCipherHashCache() that resets both variables to undefined.
• Call evictCipherHashCache() from setEngine() (after a successful engine load) and from setFips() (after setFipsCrypto(val)).
• getCurves intentionally keeps using cachedResult() — curves are not affected by FIPS mode or engine loading.

[nodejs-github-bot]

Review requested:

• @nodejs/crypto

[panva]

@srikanth-karthi thank you, this looks good on first a cursory look but can you add a test? we do have fips enabled runners in CI that could use one.

[ChALkeR]

As #62982 details mention: under BoringSSL, internal code in conditionalAlgorithms calls getHashes and getCiphers at load.

node/lib/internal/crypto/util.js

Lines 405 to 410 in bb85d23

	'ChaCha20-Poly1305': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getCiphers(),'chacha20-poly1305'),
	'cSHAKE128': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getHashes(),'shake128'),
	'cSHAKE256': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getHashes(),'shake256'),

Those results are also stale

[panva]

BoringSSL has no fips mode. And when it's not boringssl and the ciphers "become unavailable" due to a toggle switch they'll start failing with OperationError and the only inconsistency will be SubtleCrypto.supports reporting true when it should be false.

The "fips to non-fips" case 🤷

Imho not worth the churn.

[srikanth-karthi]

Thanks for the context. Agreed — under BoringSSL there's no FIPS mode so conditionalAlgorithms is stable for the process lifetime, and for OpenSSL the SubtleCrypto.supports() inconsistency after a FIPS toggle is an accepted limitation given the churn required to fix it. I'll leave conditionalAlgorithms out of scope for this PR.

[panva]

@ChALkeR what do you think about keeping the identity of the cached result the same? that way consumer can actually rely on their returned value and not get tripped up by someone elses' concern flipping fips mode.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.66%. Comparing base (85ae4cd) to head (76e61cb).
⚠️ Report is 1085 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #62985 +/- ##
=======================================
Coverage 89.66% 89.66% =======================================
Files 707 707 Lines 219501 219523 +22 Branches 42087 42092 +5 =======================================
+ Hits 196807 196832 +25 
Misses 14588 14588 + Partials 8106 8103 -3 

Files with missing lines	Coverage Δ
lib/crypto.js	93.04% <100.00%> (+0.81%)	⬆️
lib/internal/crypto/util.js	95.89% <100.00%> (+0.09%)	⬆️

... and 28 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

This pull request has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

[panva]

setFips() invalidation is superseded by #65484, I don't believe dealing with setEngine()-triggered invalidation is worth the churn since engines are on the way out of the codebase (#63966, #64777 (comment)).

[srikanth-karthi]

Fixes: #62982

Summary

getCiphers() and getHashes() used cachedResult() which memoizes on first call and never clears. Two operations mutate the OpenSSL algorithm set but did not invalidate the cache:

• setFips(true/false) — restricts/restores the visible cipher/hash list to FIPS-approved algorithms only
• setEngine(id, flags) — loads an OpenSSL engine that may register additional ciphers/hashes

This meant that after calling either function, getCiphers() and getHashes() would continue returning the stale pre-call snapshot.

Changes

• Replace the two cachedResult() calls for getCiphers/getHashes in lib/internal/crypto/util.js with manual let _ciphersCache / let _hashesCache variables — mirroring the existing _hashCache / getHashCache() pattern already in the same file.
• Add evictCipherHashCache() that resets both variables to undefined.
• Call evictCipherHashCache() from setEngine() (after a successful engine load) and from setFips() (after setFipsCrypto(val)).
• getCurves intentionally keeps using cachedResult() — curves are not affected by FIPS mode or engine loading.

[nodejs-github-bot]

Review requested:

• @nodejs/crypto

[panva]

@srikanth-karthi thank you, this looks good on first a cursory look but can you add a test? we do have fips enabled runners in CI that could use one.

[ChALkeR]

As #62982 details mention: under BoringSSL, internal code in conditionalAlgorithms calls getHashes and getCiphers at load.

node/lib/internal/crypto/util.js

Lines 405 to 410 in bb85d23

	'ChaCha20-Poly1305': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getCiphers(),'chacha20-poly1305'),
	'cSHAKE128': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getHashes(),'shake128'),
	'cSHAKE256': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getHashes(),'shake256'),

Those results are also stale

[panva]

BoringSSL has no fips mode. And when it's not boringssl and the ciphers "become unavailable" due to a toggle switch they'll start failing with OperationError and the only inconsistency will be SubtleCrypto.supports reporting true when it should be false.

The "fips to non-fips" case 🤷

Imho not worth the churn.

[srikanth-karthi]

Thanks for the context. Agreed — under BoringSSL there's no FIPS mode so conditionalAlgorithms is stable for the process lifetime, and for OpenSSL the SubtleCrypto.supports() inconsistency after a FIPS toggle is an accepted limitation given the churn required to fix it. I'll leave conditionalAlgorithms out of scope for this PR.

[panva]

@ChALkeR what do you think about keeping the identity of the cached result the same? that way consumer can actually rely on their returned value and not get tripped up by someone elses' concern flipping fips mode.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.66%. Comparing base (85ae4cd) to head (76e61cb).
⚠️ Report is 1085 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #62985 +/- ##
=======================================
Coverage 89.66% 89.66% =======================================
Files 707 707 Lines 219501 219523 +22 Branches 42087 42092 +5 =======================================
+ Hits 196807 196832 +25 
Misses 14588 14588 + Partials 8106 8103 -3 

Files with missing lines	Coverage Δ
lib/crypto.js	93.04% <100.00%> (+0.81%)	⬆️
lib/internal/crypto/util.js	95.89% <100.00%> (+0.09%)	⬆️

... and 28 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

This pull request has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

[panva]

setFips() invalidation is superseded by #65484, I don't believe dealing with setEngine()-triggered invalidation is worth the churn since engines are on the way out of the codebase (#63966, #64777 (comment)).

[srikanth-karthi]

Fixes: #62982

Summary

getCiphers() and getHashes() used cachedResult() which memoizes on first call and never clears. Two operations mutate the OpenSSL algorithm set but did not invalidate the cache:

• setFips(true/false) — restricts/restores the visible cipher/hash list to FIPS-approved algorithms only
• setEngine(id, flags) — loads an OpenSSL engine that may register additional ciphers/hashes

This meant that after calling either function, getCiphers() and getHashes() would continue returning the stale pre-call snapshot.

Changes

• Replace the two cachedResult() calls for getCiphers/getHashes in lib/internal/crypto/util.js with manual let _ciphersCache / let _hashesCache variables — mirroring the existing _hashCache / getHashCache() pattern already in the same file.
• Add evictCipherHashCache() that resets both variables to undefined.
• Call evictCipherHashCache() from setEngine() (after a successful engine load) and from setFips() (after setFipsCrypto(val)).
• getCurves intentionally keeps using cachedResult() — curves are not affected by FIPS mode or engine loading.

[nodejs-github-bot]

Review requested:

• @nodejs/crypto

[panva]

@srikanth-karthi thank you, this looks good on first a cursory look but can you add a test? we do have fips enabled runners in CI that could use one.

[ChALkeR]

As #62982 details mention: under BoringSSL, internal code in conditionalAlgorithms calls getHashes and getCiphers at load.

node/lib/internal/crypto/util.js

Lines 405 to 410 in bb85d23

	'ChaCha20-Poly1305': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getCiphers(),'chacha20-poly1305'),
	'cSHAKE128': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getHashes(),'shake128'),
	'cSHAKE256': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getHashes(),'shake256'),

Those results are also stale

[panva]

BoringSSL has no fips mode. And when it's not boringssl and the ciphers "become unavailable" due to a toggle switch they'll start failing with OperationError and the only inconsistency will be SubtleCrypto.supports reporting true when it should be false.

The "fips to non-fips" case 🤷

Imho not worth the churn.

[srikanth-karthi]

Thanks for the context. Agreed — under BoringSSL there's no FIPS mode so conditionalAlgorithms is stable for the process lifetime, and for OpenSSL the SubtleCrypto.supports() inconsistency after a FIPS toggle is an accepted limitation given the churn required to fix it. I'll leave conditionalAlgorithms out of scope for this PR.

[panva]

@ChALkeR what do you think about keeping the identity of the cached result the same? that way consumer can actually rely on their returned value and not get tripped up by someone elses' concern flipping fips mode.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.66%. Comparing base (85ae4cd) to head (76e61cb).
⚠️ Report is 1085 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #62985 +/- ##
=======================================
Coverage 89.66% 89.66% =======================================
Files 707 707 Lines 219501 219523 +22 Branches 42087 42092 +5 =======================================
+ Hits 196807 196832 +25 
Misses 14588 14588 + Partials 8106 8103 -3 

Files with missing lines	Coverage Δ
lib/crypto.js	93.04% <100.00%> (+0.81%)	⬆️
lib/internal/crypto/util.js	95.89% <100.00%> (+0.09%)	⬆️

... and 28 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

This pull request has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

[panva]

setFips() invalidation is superseded by #65484, I don't believe dealing with setEngine()-triggered invalidation is worth the churn since engines are on the way out of the codebase (#63966, #64777 (comment)).

[srikanth-karthi]

Fixes: #62982

Summary

getCiphers() and getHashes() used cachedResult() which memoizes on first call and never clears. Two operations mutate the OpenSSL algorithm set but did not invalidate the cache:

• setFips(true/false) — restricts/restores the visible cipher/hash list to FIPS-approved algorithms only
• setEngine(id, flags) — loads an OpenSSL engine that may register additional ciphers/hashes

This meant that after calling either function, getCiphers() and getHashes() would continue returning the stale pre-call snapshot.

Changes

• Replace the two cachedResult() calls for getCiphers/getHashes in lib/internal/crypto/util.js with manual let _ciphersCache / let _hashesCache variables — mirroring the existing _hashCache / getHashCache() pattern already in the same file.
• Add evictCipherHashCache() that resets both variables to undefined.
• Call evictCipherHashCache() from setEngine() (after a successful engine load) and from setFips() (after setFipsCrypto(val)).
• getCurves intentionally keeps using cachedResult() — curves are not affected by FIPS mode or engine loading.

[nodejs-github-bot]

Review requested:

• @nodejs/crypto

[panva]

@srikanth-karthi thank you, this looks good on first a cursory look but can you add a test? we do have fips enabled runners in CI that could use one.

[ChALkeR]

As #62982 details mention: under BoringSSL, internal code in conditionalAlgorithms calls getHashes and getCiphers at load.

node/lib/internal/crypto/util.js

Lines 405 to 410 in bb85d23

	'ChaCha20-Poly1305': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getCiphers(),'chacha20-poly1305'),
	'cSHAKE128': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getHashes(),'shake128'),
	'cSHAKE256': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getHashes(),'shake256'),

Those results are also stale

[panva]

BoringSSL has no fips mode. And when it's not boringssl and the ciphers "become unavailable" due to a toggle switch they'll start failing with OperationError and the only inconsistency will be SubtleCrypto.supports reporting true when it should be false.

The "fips to non-fips" case 🤷

Imho not worth the churn.

[srikanth-karthi]

Thanks for the context. Agreed — under BoringSSL there's no FIPS mode so conditionalAlgorithms is stable for the process lifetime, and for OpenSSL the SubtleCrypto.supports() inconsistency after a FIPS toggle is an accepted limitation given the churn required to fix it. I'll leave conditionalAlgorithms out of scope for this PR.

[panva]

@ChALkeR what do you think about keeping the identity of the cached result the same? that way consumer can actually rely on their returned value and not get tripped up by someone elses' concern flipping fips mode.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.66%. Comparing base (85ae4cd) to head (76e61cb).
⚠️ Report is 1085 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #62985 +/- ##
=======================================
Coverage 89.66% 89.66% =======================================
Files 707 707 Lines 219501 219523 +22 Branches 42087 42092 +5 =======================================
+ Hits 196807 196832 +25 
Misses 14588 14588 + Partials 8106 8103 -3 

Files with missing lines	Coverage Δ
lib/crypto.js	93.04% <100.00%> (+0.81%)	⬆️
lib/internal/crypto/util.js	95.89% <100.00%> (+0.09%)	⬆️

... and 28 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

This pull request has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

[panva]

setFips() invalidation is superseded by #65484, I don't believe dealing with setEngine()-triggered invalidation is worth the churn since engines are on the way out of the codebase (#63966, #64777 (comment)).

[srikanth-karthi]

Fixes: #62982

Summary

getCiphers() and getHashes() used cachedResult() which memoizes on first call and never clears. Two operations mutate the OpenSSL algorithm set but did not invalidate the cache:

• setFips(true/false) — restricts/restores the visible cipher/hash list to FIPS-approved algorithms only
• setEngine(id, flags) — loads an OpenSSL engine that may register additional ciphers/hashes

This meant that after calling either function, getCiphers() and getHashes() would continue returning the stale pre-call snapshot.

Changes

• Replace the two cachedResult() calls for getCiphers/getHashes in lib/internal/crypto/util.js with manual let _ciphersCache / let _hashesCache variables — mirroring the existing _hashCache / getHashCache() pattern already in the same file.
• Add evictCipherHashCache() that resets both variables to undefined.
• Call evictCipherHashCache() from setEngine() (after a successful engine load) and from setFips() (after setFipsCrypto(val)).
• getCurves intentionally keeps using cachedResult() — curves are not affected by FIPS mode or engine loading.

[nodejs-github-bot]

Review requested:

• @nodejs/crypto

[panva]

@srikanth-karthi thank you, this looks good on first a cursory look but can you add a test? we do have fips enabled runners in CI that could use one.

[ChALkeR]

As #62982 details mention: under BoringSSL, internal code in conditionalAlgorithms calls getHashes and getCiphers at load.

node/lib/internal/crypto/util.js

Lines 405 to 410 in bb85d23

	'ChaCha20-Poly1305': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getCiphers(),'chacha20-poly1305'),
	'cSHAKE128': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getHashes(),'shake128'),
	'cSHAKE256': !process.features.openssl_is_boringssl||
	ArrayPrototypeIncludes(getHashes(),'shake256'),

Those results are also stale

[panva]

BoringSSL has no fips mode. And when it's not boringssl and the ciphers "become unavailable" due to a toggle switch they'll start failing with OperationError and the only inconsistency will be SubtleCrypto.supports reporting true when it should be false.

The "fips to non-fips" case 🤷

Imho not worth the churn.

[srikanth-karthi]

Thanks for the context. Agreed — under BoringSSL there's no FIPS mode so conditionalAlgorithms is stable for the process lifetime, and for OpenSSL the SubtleCrypto.supports() inconsistency after a FIPS toggle is an accepted limitation given the churn required to fix it. I'll leave conditionalAlgorithms out of scope for this PR.

[panva]

@ChALkeR what do you think about keeping the identity of the cached result the same? that way consumer can actually rely on their returned value and not get tripped up by someone elses' concern flipping fips mode.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.66%. Comparing base (85ae4cd) to head (76e61cb).
⚠️ Report is 1085 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #62985 +/- ##
=======================================
Coverage 89.66% 89.66% =======================================
Files 707 707 Lines 219501 219523 +22 Branches 42087 42092 +5 =======================================
+ Hits 196807 196832 +25 
Misses 14588 14588 + Partials 8106 8103 -3 

Files with missing lines	Coverage Δ
lib/crypto.js	93.04% <100.00%> (+0.81%)	⬆️
lib/internal/crypto/util.js	95.89% <100.00%> (+0.09%)	⬆️

... and 28 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

This pull request has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

[panva]

setFips() invalidation is superseded by #65484, I don't believe dealing with setEngine()-triggered invalidation is worth the churn since engines are on the way out of the codebase (#63966, #64777 (comment)).