Hi all, I'm a Pulsar committer, writing here as an outsider to BookKeeper -- apologies in advance for anything I've misread.
I've been working on FIPS 140-3 enablement in Apache Pulsar (PIP-489). Since Pulsar embeds the BookKeeper client, I ended up reviewing BookKeeper's cryptographic surface too. I'd like to share what I found and ask whether any of it is worth a BP. One framing note first: this isn't about BookKeeper "being compliant" with FedRAMP or any other regime -- that's a property of a deployed system, not of an upstream project. The question I care about is narrower: can an operator run BookKeeper with all cryptography inside a validated module? Mostly yes, which was a pleasant surprise. Observations below are against master @ 9590a97. BookKeeper is in better shape than I expected --------------------------------------------- Compared with what Pulsar had to build, BookKeeper already has most of the pieces: - bc-fips is the primary BouncyCastle artifact (pom.xml:153, bookkeeper-server/pom.xml:120), with tests/backward-compat/bc-non-fips covering the non-FIPS swap. - TLSContextFactory resolves BCFIPS vs BC dynamically (TLSContextFactory.java:59-114). - tlsProviderFactoryClass (AbstractConfiguration.java:105) already lets an operator substitute the whole TLS factory. So I'm not proposing anything architectural. What follows is mostly mechanical. The most urgent item: bc-fips 1.0.2.5 -> 2.x --------------------------------------------- BookKeeper pins bc-fips 1.0.2.5. Checking that against the CMVP validated modules database turned up two things I didn't expect: 1. BC-FJA certificate #4616 is already on the Historical list. The listed reason is "Moved to historical list due to sunsetting," and the CMVP note is that the module "should not be included by Federal Agencies in new procurements." This isn't a future deadline -- it's the current status. 2. That certificate lists software versions "1.0.2.1, 1.0.2.2, 1.0.2.3 and 1.0.2.4". It does not list 1.0.2.5. Upstream describes 1.0.2.5 and 1.0.2.6 as patch releases of the certified 1.0.2.4 carrying security fixes, but a version absent from the certificate is outside the validated boundary. Taken together: the version shipped today doesn't appear to be a validated module, and the certificate it descends from is historical regardless. I'd appreciate a second pair of eyes on this reading, since it's the sort of thing that's easy to get wrong. FIPS 140-3 validation is on the 2.x line -- cert #4743 for 2.0.0 (active, sunset July 2029), and #4943 for 2.1.0. The bump isn't free: 2.x is API-compatible but not binary compatible, adds a required bcutil jar, and blocks PKCS#1.5 and Triple-DES in approved mode. Is anyone already looking at this? If not I'm happy to open an issue and take a first pass. Smaller gaps ------------ - tlsProvider defaults to "OpenSSL" (AbstractConfiguration.java:796), which resolves to Netty's native provider. That isn't a validated module and can't be pointed at one. Arguably just a docs/default question. - No way to pin a JSSE/JCA provider. sslContextProvider(...) is never called, and KeyStore/KeyManagerFactory/TrustManagerFactory all use JVM search order (TLSContextFactory.java:169, 199, 222). BC_PROVIDER (line 59) registers a provider as a static side effect, but the provider is never named at any call site -- so there's no way to assert that key material came from the validated module. - KeyStoreType is PKCS12/JKS/PEM defaulting to JKS (TLSContextFactory.java:124-127, ServerConfiguration.java:3437, 3494). BCFIPS doesn't provide JKS at all, and BCFKS isn't an option. - No FIPS documentation. Probably the highest-value item on this list, since it's what an operator or auditor actually consumes. The one item that looks BP-sized --------------------------------- MacDigestManager derives its MAC key with a single unsalted SHA-1 pass over the password (MacDigestManager.java:41-42, 79-84) and emits a 20-byte HmacSHA1. The construction isn't an approved KDF, and since the MAC lands in the entry format, changing it is a binary-log-format change -- which the BP policy explicitly names as a trigger. That said, I'm not sure it's worth doing. Pulsar defaults to CRC32C, so DigestType.MAC isn't on the default path for what I'd guess is most BookKeeper deployments. I'd rather hear whether anyone depends on it before proposing anything. Questions --------- 1. Is a bc-fips 2.x bump already underway or already discussed? And does my reading of the #4616 status above match yours? 2. Do the config additions (provider pinning, BCFKS, tlsProvider default) want a BP, or are individual PRs plus a docs page enough? 3. Does anyone actually depend on DigestType.MAC? I have a fuller write-up with the evidence behind each point and am happy to turn it into a BP or a docs PR, whichever the group prefers. Thanks, David Kjerrumgaard
