Hi Pulsar community, I'd like to start the discussion on PIP-489: FIPS 140-3 compliance mode for Apache Pulsar. PIP PR: https://github.com/apache/pulsar/pull/26155
Summary: Pulsar is already FIPS-capable at the JCA layer — SecurityUtility resolves the BouncyCastle vs. BC-FIPS provider reflectively — butthere is no supported FIPS deployment path. A full audit of master found the gaps this PIP addresses: 1. The BC/BC-FIPS swap lost its packaging story in the Gradle migration; the server distribution bundles non-FIPS BC and explicitlyexcludes bc-fips. 2. The broker binary listener never wires the existing tlsProvider setting, so PEM TLS is hardwired to Netty's default, which is - The BC/BC-FIPS swap lost its packaging story in the Gradle migration; the server distribution bundles non-FIPS BC and explicitly excludes bc-fips. - The broker binary listener never wires the existing tlsProvider setting, so PEM TLS is hardwired to Netty's default, which is BoringSSL (netty-tcnative is an unconditional dependency). The web/websocket/worker listeners have the same gap; the proxy wires it correctly. - Conscrypt (non-FIPS) is the shipped webServiceTlsProvider default. - Several security paths use non-approved algorithms: SHA-1-based RSA-OAEP and ECIES in MessageCryptoBc (ECIES is absent from BC-FIPS entirely, and the class compile-imports org.bouncycastle.jce.* so it fails to load on a FIPS classpath), MD5-crypt/DES-crypt in AuthenticationProviderBasic, and a non-HMAC SHA-512 construction in SaslRoleTokenSigner. - The existing bcfips test module only validates the JCA provider swap, not the TLS transport, and there is no FIPS documentation. The proposal defines FIPS mode as a deployment profile, not a fork: TLS provider wiring for every listener, a FIPS distribution variant (or documented jar-swap with first-class Gradle wiring), a fipsMode fail-fast startup validator, a metadata-negotiated migration to RSA_OAEP_SHA256 key wrapping (with ECDH+KDF+AES-KW replacing ECIES in a later phase), SHA-2-crypt support for Basic auth, a dual-verify HMAC migration for the SASL role-token signer that survives rolling upgrades, a name-stable fix for the SHA-1-derived Kubernetes resource names, and a real FIPS TLS integration test group. Implementation is phased; each phase is independently shippable, and all shipped defaults are unchanged. Three companion quick-win PRs are already open and intentionally outside the PIP: #26152 (MD5 NAR/archive checksums to SHA-256), #26153 (SHA-1 reader subscription names to SHA-256), #26154 (client TLS/crypto helper fixes for FIPS-restricted JVMs). Two open questions flagged in the document for this thread: - Whether the phase-2 FIPS distribution variant should be published to dist.apache.org or provided as a build recipe only (release-management question). - Whether to eventually revisit the Conscrypt web-TLS default once JDK TLS performance is re-benchmarked on modern JVMs (deferred in this PIP). Looking forward to your feedback. Thanks, David Kjerrumgaard
