You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by "lhotari (via GitHub)" <gi...@apache.org> on 2026/08/17 15:23:27 UTC
[PR] [improve][build] Upgrade BouncyCastle to 1.85 and BouncyCastle FIPS to 2.1.x [pulsar]
lhotari opened a new pull request, #26349:
URL: https://github.com/apache/pulsar/pull/26349
### Motivation
BouncyCastle and BouncyCastle FIPS are both behind. This brings the non-FIPS provider stack to 1.85
and the FIPS stack to the 2.1.x line.
### Modifications
`gradle/libs.versions.toml`:
| library | from | to |
|---|---|---|
| bcpkix-jdk18on / bctls-jdk18on | 1.84 | 1.85 |
| bcprov-jdk18on | 1.84 | **1.85.2** |
| bc-fips | 2.0.1 | 2.1.3 |
| bcpkix-fips | 2.0.11 | 2.1.12 |
| bcutil-fips | 2.0.6 | 2.1.7 |
Plus the corresponding jar names in the server and shell distribution `LICENSE.bin.txt` files.
**A new `bouncycastle-bcprov` version reference is introduced.** BouncyCastle published a
provider-only patch release, 1.85.2, that was *not* released for `bcpkix-jdk18on` or
`bctls-jdk18on` — those remain at 1.85 on Maven Central. `bcprov-jdk18on` previously shared the
single `bouncycastle` reference, which can no longer express this, so it now has its own.
### FIPS: please note for operators
BC-FJA 2.1.x is a **different FIPS 140-3 certified module** than 2.0.x — Certificate #4943,
certified for Java 8, 11, 17 and 21. This upgrade therefore swaps out the certified cryptographic
module underneath anyone running Pulsar in FIPS mode, which may require re-validation depending on
their compliance process. This is a compliance-relevant change, not just a version bump.
### On 1.85 release notes
BouncyCastle publishes no formal release notes for 1.85 (see bcgit/bc-java#2355). Based on the
project's release announcement, 1.85 is feature-additive over 1.84: post-quantum signature
algorithms from recent NIST and Korean standardisation work, BLS12-381 signatures, BIP-340 Taproot
Schnorr signatures, and hybrid X.509 certificate support. No API removals are announced.
Class file versions were checked in the published jars: all artifacts keep Java 8 roots with
multi-release overlays, so the Java 17 baseline is unaffected.
### Verifying this change
- [x] Make sure that the change passes the CI checks.
This change is already covered by existing tests, in particular the `tests/pulsar-client-test-bcfips`
module, which exercises the FIPS provider end to end.
Verified locally with:
- `./gradlew sanityCheck` and `./gradlew checkBinaryLicense`
- `./gradlew :tests:pulsar-client-test-bcfips:test` — passes against bc-fips 2.1.3 / bcpkix-fips
2.1.12 / bcutil-fips 2.1.7
### Does this pull request potentially affect one of the following parts:
- [x] 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
- [x] Anything that affects deployment
The FIPS module change described above affects deployments running in FIPS mode.
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] [improve][build] Upgrade BouncyCastle to 1.85 and BouncyCastle FIPS to 2.1.x [pulsar]
Posted by "nodece (via GitHub)" <gi...@apache.org>.
nodece merged PR #26349:
URL: https://github.com/apache/pulsar/pull/26349
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] [improve][build] Upgrade BouncyCastle to 1.85 and BouncyCastle FIPS to 2.1.x [pulsar]
Posted by "lhotari (via GitHub)" <gi...@apache.org>.
lhotari commented on PR #26349:
URL: https://github.com/apache/pulsar/pull/26349#issuecomment-5327921308
Thanks @david-streamlio — this was worth blocking on. You were right that the description made a certification claim the certificates don't support, and chasing it down turned up something that changes the shape of the answer. The description is rewritten; summary here.
## Your question: outcome (b), and there is no ambiguity to resolve
I went to the security policy rather than the certificate page, and it removes the guesswork — the boundary is the **jar file, by name**. [140sp4943.pdf](https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp4943.pdf) (BC-FJA, Software Version 2.1.1, 2025-07-18) §2:
> The Module is of type software and the module has a Multi-Chip Stand Alone embodiment; the cryptographic boundary is the Java Archive (JAR) file, *bc-fips-2.1.1.jar*.
So your outcome (c) is out — there is no jar-version/module-version indirection to map. Exactly one published jar per line is the validated module, and it is named in the policy. Outcome (a) is out too: 2.1.2 and 2.1.3 appear nowhere in the 58-page document, and there is no maintenance-coverage language.
BouncyCastle's own [download page](https://www.bouncycastle.org/download/bouncy-castle-java-fips/) shows the vendor side of the same structure, listing two provider jars per line — `bc-fips-2.1.0.jar` under "Provider" and `bc-fips-2.1.3.jar` under "**Provider (patched)**":
> The 2.1.0 release, BC-FJA 2.1.0 (Certificate #4943), is certified for use on Java 8, Java 11, Java 17, and Java 21. The 2.1.3 release is a patch release on 2.1.0/2.1.1/2.1.3, **going into submission**.
The [roadmap](https://www.bouncycastle.org/download/bouncy-castle-java-fips/roadmap/) fills in the middle: 2.1.1 is a "Bug fix release for 2.1.0 (GC related issues)", "Superseded by 2.1.2"; 2.1.2 is "Under submission". (BC's pages still name 2.1.0 as certified — CMVP rolled #4943 forward to 2.1.1 in its 2025-11-14 update.) So 2.1.3's status is **pending submission**: not certified, not rejected.
## Why the PR keeps 2.1.3 rather than taking your suggested fix
Your suggestion was the obvious cheap fix, and I expected to take it. It doesn't survive the CVE data. Because BouncyCastle ships security fixes **only** in the patch releases and certifies them afterwards, no certified `bc-fips` jar is free of known CVEs — on either line:
| bc-fips | Certified? | Known CVEs |
|---|---|---|
| **2.0.0** | ✅ #4743 | **11** — incl. CVE-2026-8763, CVE-2026-58062 (both CVSS 9.3) |
| 2.0.1 — *the pin this PR replaces* | ❌ | 10 — incl. the same two 9.3s |
| 2.0.2 | ❌ | 0 |
| **2.1.1** | ✅ #4943 | **13** — incl. the same two 9.3s |
| 2.1.2 | ❌ | 12 |
| **2.1.3** — this PR | ❌ pending submission | **0** |
The two criticals are certificate-validation bypasses: CVE-2026-8763 (Name Constraints bypass via a trailing dot in `rfc822Name`/URI) and CVE-2026-58062 (stapled OCSP response accepted without binding to the checked certificate). Pinning 2.1.1 to match the certificate would knowingly ship both.
One caution if you go to reproduce this: **OSV and the GitHub Advisory Database are currently stale here.** An OSV query for `org.bouncycastle:bc-fips` at 2.1.1 returns one advisory. The 2026-08-03 batch is still "Undergoing Analysis" at NVD and not yet mapped to Maven coordinates, so it has to be read from NVD directly.
And the point that decides it for this PR: **the existing `bc-fips 2.0.1` pin is not a certified version either** — #4743 names 2.0.0 only. So 2.1.3 is no worse than the status quo on certification and strictly better on CVEs. The same reasoning rules out retargeting to 2.0.2, which would also be uncertified. There is no available option that is both certified and patched; the PR picks patched, and the version catalog now carries the mapping and that trade-off in a comment so the next bump doesn't have to re-derive it.
## Your point 2 — confirmed, with a mitigating fact
The interim horizon is real: #4943 sunsets 2027-01-16 vs #4743's 2029-07-28. What takes the sting out is something I should have checked before writing that operator note: **`bc-fips` is test-only in this build.** It's declared once, as `testImplementation` in `tests/pulsar-client-test-bcfips`; `distribution/server/build.gradle.kts` explicitly excludes it; it's in no `LICENSE.bin.txt`, no published POM, and not in `pulsar-bom`. Resolving the distribution confirms it:
```
$ ./gradlew :distribution:pulsar-server-distribution:dependencies | grep -o 'org.bouncycastle:[a-z0-9-]*:[0-9.]*' | sort -u
org.bouncycastle:bcpkix-jdk18on:1.85
org.bouncycastle:bcprov-jdk18on:1.85.2
org.bouncycastle:bcutil-jdk18on:1.85
```
No `bc-fips` at any version. A FIPS deployment assembles its own provider classpath today (PIP-478 says as much), so this pin commits no operator to the shorter horizon — it determines what Pulsar's FIPS test module exercises. Which means my *"swaps out the certified cryptographic module underneath anyone running Pulsar in FIPS mode"* line was wrong on both halves: Pulsar ships no `bc-fips`, and 2.1.3 isn't the certified module. That section is gone.
## Your point 3 — confirmed, and the policy is more specific than the certificate
Beyond the tested environments (Table 2), the policy lists 78 **Vendor Affirmed** environments (Table 3) — and every one tops out at Java SE Runtime Environment v21. Java 25 is on neither list. The porting terms:
> The cryptographic module will remain compliant with the FIPS 140-3 validation when operating on any general purpose computer (GPC) provided that: 1) No source code has been modified. 2) The GPC uses the specified single-user platform, or another compatible single-user platform such as one of the Java SE Runtime Environments listed on any of the following: […]
>
> *For the avoidance of doubt, it is hereby stated that the CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate.*
Worth noting condition (1) also independently rules out reading vendor affirmation as covering a *different jar* — it varies the operational environment only. Given the test-only scoping above, for this repo the Java-25 point affects which JDK `pulsar-client-test-bcfips` runs on in CI, nothing shipped.
Also confirmed on the other two: `bcpkix-fips` and `bcutil-fips` are outside the certified boundary ("This module is the only software component within the Cryptographic Boundary"), so those bumps carry no certification consequence — they're the vendor's minimum fixed versions for their own CVEs.
## On the red CI
Agreed with your diagnosis, and it cleared on rerun — all checks are green now, no change needed.
Separately: your review surfaced that the **non-FIPS** half matters more than either of us framed it. 1.85 is the fixed version for BouncyCastle's 2026-08-03 batch, and the maintenance branches ship 1.84, so that bump is going to branch-4.2 in its own PR with the CVEs enumerated.
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org