david-streamlio commented on PR #26155: URL: https://github.com/apache/pulsar/pull/26155#issuecomment-4919017347
Thanks @lhotari — this is exactly the alignment I was hoping to get before the VOTE, and I agree with the split you propose. I've updated the PIP (95ac5afbea) accordingly: - **TLS transport now builds on PIP-478.** Design section (a) is rewritten: PIP-489 no longer defines its own TLS provider wiring. FIPS mode consumes PIP-478's `TlsPolicy` (JDK engine + JCA provider), `PulsarTlsFactory` covers the HSM/PKCS#11 (140-3 Level 3) case, and `PulsarHttpClient` brings the auth plugins' outbound HTTPS under the same configuration — that last one closes a gap I hadn't addressed (OAuth2/OIDC token-endpoint calls going through the default `SSLContext`). The per-listener one-line `.tlsProvider(...)` pass-throughs are kept only as a documented interim option for maintenance branches, explicitly not a deliverable here. PIP-489 concentrates on what PIP-478 leaves out of scope: approved algorithms in message crypto/auth, packaging, and the fail-fast `fipsMode` validator. - **Packaging stays a jar-swap story.** I've noted in General Notes that flavor selection is a classpath-assembly concern (client-side dependency exclusion/replacement; server-side separate directories or the `fipsRuntimeClasspath` variant) rather than reintroducing the Maven-era swappable modules. - **Your history points are captured in Background** — no BC JSSE dependency ever existed (pulsar-site#974), and the crypto paths haven't consistently honored an installed FIPS provider (#23122) — as motivation for making FIPS a coherent, validated capability instead of case-by-case fixes. While revising I also tightened the `fipsMode` validator to cover deployment posture, not just provider selection: keystore/truststore types (JKS rejected; PKCS12 documented unsupported — FIPS-conformant PKCS#12 needs the RFC 9879 KDF/PBMAC profile), a TLS 1.2 floor, cipher-suite and certificate-algorithm screening, and the `java.security` / BCFKS-converted-`cacerts` guidance in the deployment docs. One sequencing question for you: given PIP-489's phase 1 depends on PIP-478's `TlsPolicy` landing, do you see any issue with the two PIPs proceeding through DISCUSS/VOTE in parallel, with 489's TLS-dependent items gated on 478's implementation? -- 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]
