Skip to content

Bump shaded bouncycastle and libthrift to clear remaining CVE findings#1461

Open
vikrantpuppala wants to merge 4 commits into
mainfrom
vp/bouncycastle-libthrift-bump
Open

Bump shaded bouncycastle and libthrift to clear remaining CVE findings#1461
vikrantpuppala wants to merge 4 commits into
mainfrom
vp/bouncycastle-libthrift-bump

Conversation

@vikrantpuppala
Copy link
Copy Markdown
Collaborator

@vikrantpuppala vikrantpuppala commented May 20, 2026 •
edited
Loading

Summary

Clears the two remaining unsuppressed CVSS≥7 findings against the JDBC driver (visible via PR #1460's OSV-Scanner gate). Three commits — two version bumps and a small cleanup:

  1. bouncycastle 1.79 → 1.84 — addresses three GHSA-tracked vulnerabilities (CVE-2026-5598 severity 8.9 + two MEDIUMs). All three are NVD-CPE-invisible and were only surfaced by the new OSV-Scanner gate. One-line property bump.
  2. libthrift 0.19.0 → 0.23.0 — clears the May 2026 Apache Thrift advisory batch (GHSA-7pwc-h2j2-rjgj covering CVE-2026-41603/41604/41605/43869). Required regenerating the checked-in Thrift-generated Java sources because libthrift 0.21 broke API compatibility (added a third generic to ProcessFunction via THRIFT-5762).
  3. Remove in-repo Thrift IDL and regen script — the IDL belongs upstream (it's the shared Thrift interface for multiple SQL drivers), not duplicated here. Generated Java sources are what the Maven build consumes; deleting the IDL doesn't change behavior. Future regenerations should run against the upstream IDL/tooling.

What this PR is NOT

  • It doesn't depend on PR Unify weekly + per-PR security scanning into a single workflow #1460. The CVE findings exist on main today; this PR clears them whether or not the security-scan gate lands first.
  • It doesn't touch the upstream IDL or attempt to centralize regen tooling. That's a separate cross-driver concern that can be addressed in its own change.

Test plan

  • mvn clean install -DskipTests -Plocal succeeds across all three commits (including after the IDL/script deletion — the Maven build never referenced either).
  • mvn -pl jdbc-core test -Plocal -Dgroups='!Jvm17PlusAndArrowToNioReflectionDisabled' — 3288 tests, 0 failures, 0 errors after the libthrift regen.
  • mvn dependency:tree confirms resolved versions: libthrift 0.23.0, bcprov-jdk18on 1.84, bcpkix-jdk18on 1.84.
  • Full PR CI on this PR (will go green via the gate from Unify weekly + per-PR security scanning into a single workflow #1460 once both PRs are on main).

Follow-up: flip security-scan to required

Once both this PR and #1460 land, the PR security-scan gate from #1460 should have zero unsuppressed CVSS≥7 findings on main. That's the cue to flip the gate's check to required-to-merge in branch protection (the explicit plan from #1460).

This pull request and its description were written by Isaac.

@vikrantpuppala
Bump shaded bouncycastle 1.79 to 1.84
4636061 
Addresses three GHSA-tracked vulnerabilities in bcprov-jdk18on and
bcpkix-jdk18on that are invisible to NVD-CPE scanners but surface
through OSV:

  * GHSA-p93r-85wp-75v3 (CVE-2026-5598) -- covert timing channel,
    severity 8.9, fixed in 1.84
  * GHSA-wg6q-6289-32hp -- bcpkix vulnerability, severity 6.3
  * GHSA-c3fc-8qff-9hwx -- bcprov vulnerability, severity 5.5

All three were discovered while building the OSV-Scanner gate in #1460,
which catches GHSA-only advisories that OWASP's NVD-CPE matcher misses.

Co-authored-by: Isaac
Signed-off-by: Vikrant Puppala <vikrant.puppala@databricks.com>
@vikrantpuppala
Bump shaded libthrift 0.19.0 to 0.23.0 (regenerated Java sources)
305529a 
Clears the May 2026 Apache Thrift advisory batch (GHSA-7pwc-h2j2-rjgj
covering CVE-2026-41603/41604/41605/43869). All four affect parser
paths and were the only libthrift CVEs in that batch not already
suppressed as non-Java-binding false positives.

The bump required regenerating the checked-in Thrift-generated Java
sources because libthrift 0.21 added a third generic parameter to
`org.apache.thrift.ProcessFunction` via THRIFT-5762, which made the
existing TCLIService.java (generated by Thrift 0.19) fail to compile
against the 0.23 runtime ("wrong number of type arguments; required 3"
on every AsyncMethodCallback callsite).

Regeneration steps documented in the new scripts/regenerate-thrift.sh:

  1. Builds the Apache Thrift 0.23.0 compiler from source (the
     official Docker images aren't versioned past 0.12.0; building
     compiler-only with --enable-libs=no takes <1 min).
  2. Runs `thrift --gen java` against the IDL at
     jdbc-core/src/main/java/com/databricks/jdbc/dbclient/impl/thrift/
     TCLIService.thrift.
  3. Replaces the contents of
     jdbc-core/src/main/java/com/databricks/jdbc/model/client/thrift/
     generated/ (~107 files).
  4. Runs `mvn spotless:apply` so the new sources match the project's
     formatting.

The IDL has also been re-synced from the canonical source at
~/universe/peco/thrift/TCLIService.thrift (per the README there, this
IDL feeds the Python, Node.js, Go, and Java SQL drivers). The
in-repo copy is identical except for a 2-line comment header.

Verified locally:
  - mvn clean install -DskipTests -Plocal succeeds.
  - mvn -pl jdbc-core test -Plocal -Dgroups='!Jvm17PlusAndArrowToNio
    ReflectionDisabled' passes 3288 tests with 0 failures, 0 errors.

Co-authored-by: Isaac
Signed-off-by: Vikrant Puppala <vikrant.puppala@databricks.com>
@vikrantpuppala
Remove in-repo Thrift IDL and regen script
c1688f6 
The canonical IDL is maintained upstream as part of the shared Thrift
interface for SQL drivers; carrying a copy in this repo creates drift
risk without adding value. The generated Java sources (~107 files in
src/main/java/com/databricks/jdbc/model/client/thrift/generated/) are
what the build actually consumes, so removing the IDL doesn't change
behavior or the Maven build.

Drops:
  - src/main/java/com/databricks/jdbc/dbclient/impl/thrift/TCLIService.thrift
  - scripts/regenerate-thrift.sh (no longer needed without the IDL)

When a future libthrift bump requires regenerating the generated code,
that should happen against the upstream IDL and tooling, not from a
copy here.

Co-authored-by: Isaac
Signed-off-by: Vikrant Puppala <vikrant.puppala@databricks.com>
@vikrantpuppala
Fix NPE in DatabricksHttpTTransport.getConfiguration() under libthrif…
11b1500 
…t 0.23

libthrift 0.21+ began dereferencing the return value of
TTransport.getConfiguration() in the message-reading code path (e.g.
TProtocolUtil.readMessageBegin reads the recursion limit). Our custom
DatabricksHttpTTransport returned null, which worked under 0.19 (where
the framework tolerated null) but throws NullPointerException under
0.23:

  java.lang.NullPointerException: Cannot invoke
  "org.apache.thrift.TConfiguration.getRecursionLimit()" because the
  return value of "org.apache.thrift.transport.TTransport.getConfiguration()"
  is null

This caused 182 errors across the THRIFT_SERVER fake-service integration
test matrix in the previous CI run on this PR. The unit-test suite
didn't catch it because integration tests are excluded from the
unit-test group (they require a fake service running).

Fix: return TConfiguration.DEFAULT (libthrift's built-in default).
DatabricksHttpTTransport doesn't need a custom configuration because
it's an HTTP-based transport with bounded message sizes governed by
the HTTP client, not by Thrift framing.

Verified locally:
  - 106 thrift-related unit tests pass.
  - The TConfiguration NPE no longer appears in surefire reports when
    running ResultSetIntegrationTests with FAKE_SERVICE_TYPE=THRIFT_SERVER.

Co-authored-by: Isaac
Signed-off-by: Vikrant Puppala <vikrant.puppala@databricks.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@vikrantpuppala