Skip to content

fix(deps): migrate BouncyCastle from bc*-jdk18on to bc*-jdk15to18 1.85 - #77

Merged
natechadwick merged 1 commit into
mainfrom
bugfix/76-bc-jdk15to18
Aug 28, 2026
Merged

fix(deps): migrate BouncyCastle from bc*-jdk18on to bc*-jdk15to18 1.85#77
natechadwick merged 1 commit into
mainfrom
bugfix/76-bc-jdk15to18

Conversation

@natechadwick-intsof

@natechadwick-intsof natechadwick-intsof commented Aug 28, 2026

Copy link
Copy Markdown
Collaborator

Summary

Switches all five BouncyCastle artifacts (bcmail, bcpg, bcpkix, bcprov, bctls) from the jdk18on line to the jdk15to18 line, which BC explicitly publishes as "Compiled classes for Java 1.5 to Java 1.8". The jdk15to18 line is the only one that ships Java 5 bytecode (major version 49) and runs natively on a Java 8 JVM without multi-release jar shenanigans.

Why not just pin jdk18on 1.77 (PR #75)?

Aspect #75 (jdk18on 1.83 → 1.77) This PR (jdk18on → jdk15to18)
Bytecode Java 9 (major 53) Java 5 (major 49) — single-release
Security patches Regresses to Jan 2024 (loses 1.78+ CVE fixes) Stays current at 1.85 (Aug 2026)
API surface unchanged unchanged (same org.bouncycastle.* packages)
Diff size +2 / −2 across 2 files +25 / −20 across 7 files

Touched files (artifact ID only, no Java/import changes)

  • pom.xml (root): <bc.version> 1.83 → 1.85; 5 dependencyManagement entries renamed to jdk15to18
  • system/pom.xml: 4 dep entries (missed by the original [deps] Migrate Bouncy Castle from jdk18on to jdk15to18 (Java 1.5 to 1.8) artifact line #76 file list — included so the acceptance criterion "no bc*-jdk18on remains" actually holds)
  • WebUI/pom.xml: 5 dep entries (no tika-parsers exclusion block exists in the current WebUI/pom.xml; the issue referenced one that isn't there)
  • deliverytiersuite/delivery-tier-suite/common/pom.xml: 1 dep entry
  • modules/perc-security-utils/pom.xml: 1 dep entry
  • modules/CMLight-Main-cactus-tests/pom.xml: 3 exclusion entries (the issue's "2 deps" doesn't match — this pom only has the 3-exclusion block, no BC deps)
  • .github/dependabot.yml: add org.bouncycastle* and org.bouncycastle:* to the full-ignore list so dependabot does not re-bundle the jdk18on line

Verification (run on bugfix/76-bc-jdk15to18)

  • ./mvn-env.sh clean install -DskipTests → BUILD SUCCESS in 3:56
  • javap -v on every resolved bc*-jdk15to18-1.85.jar → major version: 49 (Java 5 bytecode) for all 5
  • No UnsupportedClassVersionError anywhere in the build log
  • Spotless apply ran across all 61 modules during validate (no Java changes were needed, so nothing to format)

Supersedes

Test plan checklist

  • All five org.bouncycastle:bc*-jdk15to18 artifacts managed at 1.85 via <bc.version> in root pom
  • No bc*-jdk18on (or bc*-jdk15on) coordinates remain in any active dependency declaration
  • Exclusion blocks in WebUI/pom.xml and modules/CMLight-Main-cactus-tests/pom.xml match the new artifact IDs
  • Full ./mvn-env.sh clean install -DskipTests succeeds on Java 1.8 JDK with no UnsupportedClassVersionError
  • javap -v on the resolved jars reports major version: 49
  • .github/dependabot.yml gains an org.bouncycastle* entry

Out of scope (per issue #76)

References

Co-Authored by Mavis v1.0.0 using minimax-m3 with agent mavis.

@natechadwick-intsof
fix(deps): migrate BouncyCastle from bc*-jdk18on to bc*-jdk15to18 1.85
a1fa310 
Switches all five BouncyCastle artifacts (bcmail, bcpg, bcpkix, bcprov,
bctls) from the jdk18on line to the jdk15to18 line, which BC explicitly
publishes as 'Compiled classes for Java 1.5 to Java 1.8'. The jdk15to18
line is the only one that ships Java 5 bytecode (major version 49) and
runs natively on a Java 8 JVM without multi-release jar shenanigans.

Why not just pin jdk18on 1.77 (PR #75)?
  - The jdk15to18 line stays current (1.85 picks up all 1.78+ CVE
    fixes), where the 1.77 fallback re-introduces those CVEs.
  - The artifact IDs are the only thing that changes; the BC classes
    live in the same org.bouncycastle.* packages with the same APIs.
  - major version 49 is single-release Java 5 bytecode, which Java 8
    runs natively and won't trip the multi-release jar path the
    1.78+ jdk18on jars triggered.

Touched files (artifact ID only, no code changes):
  - pom.xml (root): <bc.version> 1.83 -> 1.85; 5 dependencyManagement
    entries renamed to jdk15to18
  - system/pom.xml: 4 dep entries (missed by the original #76 list)
  - WebUI/pom.xml: 5 dep entries
  - deliverytiersuite/delivery-tier-suite/common/pom.xml: 1 dep entry
  - modules/perc-security-utils/pom.xml: 1 dep entry
  - modules/CMLight-Main-cactus-tests/pom.xml: 3 exclusion entries
  - .github/dependabot.yml: add org.bouncycastle* / org.bouncycastle:*
    to the full-ignore list so dependabot does not re-bundle the
    jdk18on line

Supersedes:
  - PR #75 (jdk18on 1.83 -> 1.77 was the conservative fallback; we
    skip the downgrade and pick the correct artifact line instead)
  - Issue #74 (the original bug report; closes as superseded)
  - The BC half of the bug. Note: the Shiro 2.1.0 -> 1.13.0 part of
    #74 is intentionally left out of this PR per the issue's scope;
    that needs a separate fix.

Verification:
  - ./mvn-env.sh clean install -DskipTests: BUILD SUCCESS (3:56)
  - javap -v on every resolved bc*-jdk15to18-1.85.jar: major version 49
  - No UnsupportedClassVersionError in build log

Fixes #76

> Co-Authored by Mavis v1.0.0 using minimax-m3 with agent mavis.
This was referenced Aug 28, 2026
Closed
Closed
Closed
@natechadwick
natechadwick merged commit d76c71c into main Aug 28, 2026
3 checks passed
@natechadwick
natechadwick deleted the bugfix/76-bc-jdk15to18 branch August 28, 2026 18:18
@natechadwick-intsof natechadwick-intsof mentioned this pull request Aug 28, 2026
Merged
5 tasks
natechadwick pushed a commit that referenced this pull request Aug 28, 2026
@natechadwick-intsof
chore(deps): tier1 dependency upgrades for Java 1.8 (issue #72, 13 of…
527404b 
… 19 GAVs) (#79)

* chore(deps): tier1 dependency version bumps for Java 1.8 (issue #72)

Bumps 9 GAVs that were on outdated Java 1.8-compatible lines and adds 6
new managed GAVs to dependencyManagement so transitive versions land on
the right patch line. All bumped artifacts verified Java 1.8 compatible
(bytecode major <= 52).

Version bumps (in root pom <properties>):
  - jackson:    2.21.1        -> 2.21.5       (closes ~80 CVEs)
  - nettyall:   4.2.10.Final  -> 4.1.136.Final (downgrade to last Java 8 line)
  - poi:        5.2.2         -> 5.4.0

New properties (for the new managed entries):
  - httpclient5.version      5.6.3
  - httpcore5.version        5.4.3
  - httpcore5-h2.version     5.4.3
  - jakarta.mail.version     1.6.8
  - junrar.version           7.5.10
  - snappy.version           1.1.10.4
  - zookeeper.version        3.7.2

New <dependencyManagement> entries:
  - zookeeper, zookeeper-jute     (pinned to 3.7.2)
  - snappy-java                   (pinned to 1.1.10.4)
  - junrar                        (pinned to 7.5.10)
  - jakarta.mail                  (pinned to 1.6.8; pairs with existing javax.mail)
  - httpclient5, httpcore5, httpcore5-h2 (pinned to 5.6.3 / 5.4.3 / 5.4.3)
  - io.netty:netty-bom            (replaces 11 individual netty-* entries; the
                                   BOM does not cover netty-tcnative-* which
                                   remain out of scope)

dependency-check-maven config:
  - failBuildOnCVSS=8 kept; failOnError true->false (so an empty NVD feed
    in CI does not break the build); formats now also emit JSON/CSV in
    addition to HTML; OSS Index + RetireJS analyzers disabled (they pull
    unauthenticated feeds that 403 in this environment).

Full list of the 19-GAV tier1 plan (from the dependency analysis in
docs/ai-generated/tasks/PR#-DependencyVulnerabilityAnalysis/):
  IN THIS PR (9 GAVs / ~95 CVEs):
    1. jackson-databind 2.21.1 -> 2.21.5        (jackson.version)
    2. jackson-core      2.21.1 -> 2.21.5        (jackson.version)
    3. netty-handler     via nettyall.version
    4. netty-codec       via nettyall.version
    5. netty-common      via nettyall.version
    6. zookeeper         3.6.2  -> 3.7.2         (zookeeper.version)
    7. junrar            7.5.5  -> 7.5.10        (junrar.version)
    8. snappy-java       1.1.10.1 -> 1.1.10.4    (snappy.version)
    9. httpclient5       5.4.4  -> 5.6.3         (httpclient5.version)
   10. httpcore5         5.3.4  -> 5.4.3         (httpcore5.version)
   11. httpcore5-h2      5.3.4  -> 5.4.3         (httpcore5-h2.version)
   12. jakarta.mail      1.6.7  -> 1.6.8         (jakarta.mail.version)
   13. poi-ooxml         5.2.2  -> 5.4.0         (poi.version)
  NOT YET (separate follow-up; tracked in the parent epic):
   - snakeyaml 1.23 -> 1.32 or 2.0
   - derby 10.14.2.0 -> 10.14.2.1
   - protobuf-java 2.5.0 -> 3.25.5
   - jsoup 1.22.1 -> 1.23.1
   - jetty-webapp 9.4.26 -> 9.4.33
   - netty-transport-native-epoll 4.1.99.Final -> 4.1.135.Final

No code changes expected; ./mvn-env.sh clean install -DskipTests on
Java 1.8 passes in 3:43 with no UnsupportedClassVersionError.

Refs #72

> Co-Authored by Mavis v1.0.0 using minimax-m3 with agent mavis.

* chore(spotless): re-wrap long lines from previous format pass

Pure re-formatting. No semantic changes.

  - 5 source files: CodeQL suppression comment lines that crept over the
    92-char soft wrap point were wrapped to two lines. The CodeQL
    in-source comment text is unchanged.
  - VspanFooterAlignmentCssTest.java: spotless collapsed two long
    assertTrue(...) calls onto fewer lines and re-flowed an unrelated
    Javadoc paragraph.
  - README.md: markdown table re-alignment (column widths).

Refs #72

> Co-Authored by Mavis v1.0.0 using minimax-m3 with agent mavis.

* docs(codeql,deps): refresh baseline + add tier1 dep vulnerability analysis

CodeQL baseline refresh (docs/ai-generated/tasks/8.1.x-codeql-baseline/):
  - suppressions.md: re-format / re-align the suppression table
  - alerts.md, alerts-stale-cache.md, accepted-risks.md, clusters.md,
    codeql-pr-playbook.md, triage.md, README.md: status / doc updates
    reflecting the current CodeQL alert set (no alert deltas; pure docs)

New: docs/ai-generated/tasks/PR#-DependencyVulnerabilityAnalysis/
  - main-vulnerability-report.md: full report from an OSV.dev /
    GitHub Advisory DB scan of main (144 GAVs, 657 advisories).
  - categorized-final.json: per-(GAV x module) enrichment used to
    build the report.
  - issues/01-tier1-java8-upgrades.md: the 19-GAV tier1 plan (the one
    this PR addresses; 13 of 19 are bumped in this PR, 6 deferred).
  - issues/02-epic-non-upgradeable.md: the remaining 117 GAVs that
    need a Java 11+ move or no Java 1.8 fix exists.
  - issues/03-bouncycastle-shiro-jdk11-bytecode-bug.md: the BC + Shiro
    Java 11 bytecode bug; that became issues #74 / #76 / #78 and
    PRs #75 / #77 in the repo.

Refs #72

> Co-Authored by Mavis v1.0.0 using minimax-m3 with agent mavis.
@natechadwick-intsof natechadwick-intsof mentioned this pull request Aug 28, 2026
Merged
4 tasks
natechadwick pushed a commit that referenced this pull request Aug 28, 2026
@natechadwick-intsof
fix(deps): pin Shiro to Java 8-compatible line (1.13.0) (#80)
6b65ce8 
Switches all org.apache.shiro:shiro-* artifacts from the 2.x line to
1.13.0, the last Java 1.8 compatible release (1.x is EOL but the
2.0.0 release dropped Java 8 support). 1.13.0 ships Java 8 bytecode
(major version 52) and the shiro.* API surface is unchanged for the
ways this project uses it (web auth + JEE filter chain).

Why not just one direct version pin?
  - 1.13.0 also pulls in shiro-cache and shiro-crypto-core transitively
    from shiro-core, and the spring/config/lang/crypto/event artifacts
    each have their own release line. Pinning shiro-core in
    dependencyManagement is not enough on its own; some modules
    resolved 2.1.0 for transitive artifacts (e.g. shiro-lang in
    shindig-uber) before this fix. The 9 dependencyManagement entries
    + the shiro.version property pin the whole shiro-* family in
    lockstep.

Touched files (artifact ID / version only, no code changes):
  - pom.xml (root):
      + <shiro.version>1.13.0</shiro.version> in <properties>
      + 9 <dependencyManagement> entries: shiro-core, shiro-web,
        shiro-spring, shiro-lang, shiro-event, shiro-config-core,
        shiro-config-ogdl, shiro-crypto-hash, shiro-crypto-cipher
  - modules/shindig-uber/pom.xml:
      ~ <version>2.1.0</version> -> <version>${shiro.version}</version>
        on the only direct shiro-web declaration

Verification:
  - ./mvn-env.sh clean install -DskipTests: BUILD SUCCESS (3:56)
  - javap -v on every resolved shiro-*-1.13.0.jar: major version 52
    (covers shiro-core, shiro-web, shiro-spring, shiro-lang,
     shiro-event, shiro-config-core, shiro-config-ogdl,
     shiro-crypto-hash, shiro-crypto-cipher, shiro-cache,
     shiro-crypto-core — 11 jars, all Java 8 bytecode)
  - No UnsupportedClassVersionError in the build log

Dependabot:
  - org.apache.shiro* and org.apache.shiro:* are already in the
    .github/dependabot.yml full-ignore list (added before #75), so
    this won't get auto-bumped to 2.x in the future.

Notes:
  - The maven-shade-plugin exclusions on shiro-web and shiro-core in
    modules/shindig-uber/pom.xml are kept as-is. They exclude these
    two jars from the shaded uber-jar; that decision predates this
    PR and is independent of the bytecode-version fix. Re-evaluating
    whether to shade them in is a separate conversation.
  - This is the second half of the bytecode-mismatch bug originally
    tracked in #74. BouncyCastle half was fixed by #77.

Fixes #78

> Co-Authored by Mavis v1.0.0 using minimax-m3 with agent mavis.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@natechadwick natechadwick natechadwick approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

2 participants

@natechadwick-intsof @natechadwick