david-streamlio opened a new pull request, #26154:
URL: https://github.com/apache/pulsar/pull/26154
### Motivation
Two client-path helpers hardcode SUN-provider-specific choices that fail or
fall back to non-approved crypto on JVMs running a restricted security
configuration (e.g. BC-FIPS in approved-only mode):
1. `MessageCryptoBc` pins
`SecureRandom.getInstance("NativePRNGNonBlocking")` for data-key and GCM-IV
generation. That algorithm doesn't exist in FIPS providers, and even when the
fallback engages, randomness is sourced outside the FIPS-validated module. NIST
SP 800-38D permits random 96-bit GCM IVs only when generated by an approved
DRBG.
2. `KeyManagerProxy` (the auto-refreshing PEM key manager) hardcodes
`KeyStore.getInstance("JKS")` for its in-memory keystore, which fails where the
JKS keystore type is unavailable.
This is one of a set of small preparatory cleanups for FIPS-restricted
deployments; a broader PIP is being drafted separately.
### Modifications
- `MessageCryptoBc`: when a `BCFIPS` provider is registered, obtain
`SecureRandom.getInstance("DEFAULT", bcfips)` — the BC-FIPS SP 800-90A DRBG —
so key/IV generation stays within the FIPS-validated module. Only *registered*
providers are consulted (`Security.getProvider`), deliberately avoiding
BouncyCastle classpath resolution during class loading, consistent with the
existing lazy `BcProviderHolder` design. Behavior on standard JVMs is unchanged
(`NativePRNGNonBlocking`, falling back to `new SecureRandom()`).
- `KeyManagerProxy`: keep JKS as the preferred in-memory keystore type, but
fall back to `KeyStore.getDefaultType()` when JKS is unavailable. JKS remains
preferred deliberately: PKCS12's `setKeyEntry` rejects certificate lists that
do not form a linked chain, which JKS accepts — switching unconditionally to
the default type breaks `KeyManagerProxyTest`'s multiple-CA case (verified
while developing this change).
### Verifying this change
- [x] Make sure that the change passes the CI checks.
This change is already covered by existing tests: `KeyManagerProxyTest`
(including the multiple-CA chain case that pins the JKS-preferred behavior) and
`RawBatchMessageContainerImplTest` (exercises `MessageCryptoBc` encryption
end-to-end). The `BCFIPS` branch cannot be exercised without a FIPS-registered
JVM; it is compile-verified, and the `DEFAULT` SecureRandom service is
confirmed present in `bc-fips` 2.0.1.
### Does this pull request potentially affect one of the following parts:
- [ ] Dependencies (add or upgrade a dependency)
- [ ] The public API
- [ ] The schema
- [ ] The default values of configurations
- [ ] The threading model
- [ ] The binary protocol
- [ ] The REST endpoints
- [ ] The admin CLI options
- [ ] The metrics
- [ ] Anything that affects deployment
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
