[FIPS] connectivity: jks-js pulls non-FIPS crypto (MD5, SHA-1, DES) into all consumers

[RyanLiu0530]

Summary

@sap-cloud-sdk/connectivity unconditionally depends on jks-js, which brings node-forge and node-rsa into the production dependency tree of every consumer. These three packages implement non-FIPS algorithms (MD5, SHA-1, DES, 3DES, AES-ECB, RIPEMD-160, RSA+MD5, RSA+SHA-1) in pure JavaScript, bypassing the OpenSSL FIPS provider. Any consumer that must pass a FIPS compliance scan (including SAP Datasphere) is blocked.

Dependency chain

@sap-cloud-sdk/connectivity@4.9.1
  → jks-js@1.1.7          (MD5, SHA-1, DES via node-forge)
    → node-forge@1.4.0    (MD5, SHA-1, DES, 3DES, AES-ECB, RIPEMD-160)
    → node-rsa@1.1.1      (RSA+MD5, RSA+SHA-1)

jks-js was introduced in #6153 (commit ab96aff) to add JKS keystore support. Verified against latest @sap-cloud-sdk/connectivity@4.9.1 — still present.

Impact

Consumers that only use PEM certificates never reach the JKS code path at runtime, but the non-FIPS packages remain in node_modules and are flagged by FIPS compliance scanners. Example: SAP Datasphere's @sap/dwc-ucl-odata-client uses ClientCertificateAuthentication with type: 'pem' exclusively — no JKS use — yet is still blocked.

Tracked internally: DC00-6780 (parent evaluation), DC00-6815 (Datasphere remediation).

Suggested fix

Escalate to @sap-cloud-sdk maintainers to either:

1. Replace jks-js with a FIPS-compatible JKS keystore parser, or
2. Make JKS support opt-in so services that don't use it avoid the dependency entirely.

Ask

• Confirm which direction the team prefers.
• Provide a rough timeline so downstream consumers can plan.

cc: @davidkna-sap @KavithaSiva @emincihangeri