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 4 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.