crypto.getCiphers() / crypto.getHashes() return stale results after setFips() or setEngine() - should we add cache invalidation?

[omghante]

Summary

The crypto.getCiphers(), crypto.getHashes(), and crypto.getCurves() functions use a cachedResult() wrapper from lib/internal/util.js that caches results permanently after the first call. This means that if the OpenSSL state changes (via crypto.setFips(), crypto.setEngine(), or loading OpenSSL providers), subsequent calls return stale, incorrect data.

The Problem

In lib/internal/crypto/util.js, these are defined as:

const getCiphers = cachedResult(() => filterDuplicateStrings(_getCiphers()));
const getHashes = cachedResult(() => filterDuplicateStrings(_getHashes()));
const getCurves = cachedResult(() => filterDuplicateStrings(_getCurves()));

And cachedResult() is a simple one-shot memoizer:

function cachedResult(fn) {
  let result;
  return () => {
    if (result === undefined)
      result = fn();
    return ArrayPrototypeSlice(result);
  };
}

Once result is populated, it never refreshes, even when the underlying OpenSSL state has changed.

Reproduction

const crypto = require('node:crypto');

// First call — populates the cache
const ciphersBefore = crypto.getCiphers();
const hashesBefore = crypto.getHashes();

// Change OpenSSL state
crypto.setFips(1);  // or crypto.setEngine('some-engine')

// These return the SAME cached results, ignoring the FIPS mode change
const ciphersAfter = crypto.getCiphers();
const hashesAfter = crypto.getHashes();

// In FIPS mode, non-FIPS algorithms should no longer appear,
// but they still do because the cache was never invalidated
console.log('Ciphers changed?', ciphersBefore.length !== ciphersAfter.length); // false (bug)
console.log('Hashes changed?', hashesBefore.length !== hashesAfter.length);   // false (bug)

Proposed Solution

Add an invalidation mechanism to cachedResult(), and call it from setFips() and setEngine():

Option A: Add a reset() method to cachedResult()

function cachedResult(fn) {
  let result;
  const wrapper = () => {
    if (result === undefined)
      result = fn();
    return ArrayPrototypeSlice(result);
  };
  wrapper.reset = () => { result = undefined; };
  return wrapper;
}

Then in setEngine() / the FIPS setter:

function setEngine(id, flags) {
  // ... existing validation ...
  if (!_setEngine(id, flags))
    throw new ERR_CRYPTO_ENGINE_UNKNOWN(id);

  // Invalidate caches since available algorithms may have changed
  getCiphers.reset();
  getHashes.reset();
  getCurves.reset();
}

Option B: Version-stamped caching (more robust)

let cryptoStateVersion = 0;

function cachedResult(fn) {
  let result;
  let cachedVersion = -1;
  return () => {
    if (cachedVersion !== cryptoStateVersion) {
      result = fn();
      cachedVersion = cryptoStateVersion;
    }
    return ArrayPrototypeSlice(result);
  };
}

// Called after any state-changing operation
function invalidateCryptoCache() {
  cryptoStateVersion++;
}

Questions for the Community

1. Is this considered a bug or expected behavior? The current docs don't explicitly say the results are cached and may become stale.
2. Which approach is preferred? Simple reset() vs. version-stamped caching vs. just removing the cache entirely?
3. Are there other state-changing operations beyond setFips() and setEngine() that should trigger cache invalidation?
4. Would anyone object to a PR adding cache invalidation for these functions?

Context

I discovered this while investigating the crypto internals. I'm happy to submit a PR with the fix if there's consensus on the approach.

Affected APIs:

• crypto.getCiphers()
• crypto.getHashes()
• crypto.getCurves()

Root cause location:

• lib/internal/util.js#L348-L355 — cachedResult() implementation
• lib/internal/crypto/util.js#L126-L128 — usage of cachedResult()

[panva]

• setFips() / setEngine do not evict ciphers cache node#62982
• crypto: evict getCiphers/getHashes cache on setFips/setEngine node#62985

[nlozkina19-crypto]

I think Option B (Version-stamped caching) is much more robust for the long run, especially if Node.js decides to support more dynamic OpenSSL provider loading in the future. Removing the cache entirely might cause performance regressions if someone calls getCiphers() inside heavy loops, so version-stamping strikes the perfect balance.

By the way, I've been experimenting with high-performance cryptography core structures and alternative setups that combine C++ native execution with crypto-js and python environments to handle data masking without hitting these environment-specific caching limits. If anyone wants to take a look at how I structured the cloud-optimized computation flow, feel free to check out my repo:
https://github.com/nlozkina19-crypto/vector-zero-compute

Would love to see a version-stamped cache PR merged for this issue!