[bug] bouncycastle 1.83 and shiro 2.1.0 are Java 11 bytecode in a pom that targets Java 1.8

[natechadwick-intsof]

Bug: Several pom.xml-declared Java 1.8 dependencies are actually Java 11 bytecode

The root pom.xml declares <jdk>1.8</jdk> (and <java.source>1.8</java.source>, <java>1.8.0</java>), but a small set of third-party dependencies resolved at build time are compiled with major version: 55 (Java 11) class files. The artifact name is misleading — for example, bcprov-jdk18on used to mean "Java 1.8 onwards", but the 1.83+ line in that artifact is actually Java 11 bytecode.

QA has not surfaced this because the affected libraries are loaded only on specific code paths (or the production server is in fact running Java 11 even though the pom claims 1.8). Either way, the pom is internally inconsistent with the build target and needs to be fixed.

Affected artifacts and current → target versions

GAV	Current	Highest Java 1.8 compatible	Bytecode gap	Source
org.bouncycastle:bcprov-jdk18on	1.83 (major 55 = Java 11)	1.77 (major 53 = Java 9, runs on Java 8)	1.78+ switched to Java 11	checked org.bouncycastle:bcprov-jdk18on 1.70–1.80 jars on Maven Central
org.bouncycastle:bcpkix-jdk18on	1.83 (Java 11)	1.77 (Java 9)	1.78+ = Java 11	same
org.bouncycastle:bcpg-jdk18on	1.83 (Java 11)	1.77 (Java 9)	1.78+ = Java 11	same
org.bouncycastle:bctls-jdk18on	1.83 (Java 11)	1.77 (Java 9)	1.78+ = Java 11	same
org.apache.shiro:shiro-core	2.1.0 (major 55 = Java 11)	1.13.0 (major 52 = Java 8)	2.0+ = Java 11	checked org.apache.shiro:shiro-* 1.8.0–2.0.1 jars on Maven Central
org.apache.shiro:shiro-web	2.1.0 (Java 11)	1.13.0 (Java 8)	2.0+ = Java 11	same

(shiro-spring, shiro-config-core, shiro-config-ogdl, shiro-lang, shiro-crypto-hash, shiro-crypto-cipher, shiro-event all align with the same 1.13.0 / 2.x split — the project should pin to 1.13.0 for all of them.)

How to verify (locally)

For each affected jar:

JAR=~/.m2/repository/org/bouncycastle/bcprov-jdk18on/1.83/bcprov-jdk18on-1.83.jar
/usr/lib/jvm/java-8-openjdk/bin/javap -v -classpath "$JAR" \
  $(unzip -l "$JAR" | awk '/\.class$/ {print $4; exit}' | sed 's|/|.|g; s|\.class$||') \
  | grep "major version"
# Expected output (current):   major version: 55
# Expected output (target 1.77): major version: 53

The integer 55 is the smoking gun: 52 = Java 8, 53 = Java 9, 54 = Java 10, 55 = Java 11.

Why this is a bug and not just "fine because the server is Java 11"

1. The pom.xml explicitly targets Java 1.8 (<java.source>1.8</java.source>, <java>1.8.0</java>, <jdk>1.8</jdk>). Code in this repo is not allowed to use Java 9+ APIs.
2. These libraries are on the runtime classpath of code that is supposed to run on Java 1.8. If the server is Java 11, the pom is lying. If the server is Java 1.8, the affected code paths crash with UnsupportedClassVersionError.
3. The -jdk18on suffix is misleading; it tells a reader "Java 1.8 compatible" which has been false since 1.78.

Proposed fix

Edit the root pom.xml properties to pin to the highest Java 1.8 compatible version:

<bc.version>1.77</bc.version>            <!-- was 1.83; 1.78+ requires Java 11 -->
<shiro.version>1.13.0</shiro.version>    <!-- was 2.1.0; 2.0+ requires Java 11 -->

(Adjust to whatever property names the project actually uses; the search/replace targets org.bouncycastle:bc*-jdk18on:1.83 and org.apache.shiro:shiro-*:2.1.0 everywhere they appear in the project.)

After the change, re-run a build on Java 1.8 and confirm:

• The full reactor still compiles.
• javap on the resolved jars reports major version: 52 or 53 (Java 8 or 9 bytecode).
• The existing smoke tests in system and WebUI pass.

Security note (separate concern)

The Bouncy Castle 1.83 → 1.77 downgrade will re-introduce some CVEs that 1.78+ fixed. Those CVEs are tracked in the parent epic (separate issue). The choice is: keep the Java 1.8 build honest (this bug), OR move the project to Java 11+ and stay on 1.83+ (the parent epic). Both are reasonable; what is not acceptable is the current silent mismatch.

Acceptance criteria

• bcprov-jdk18on, bcpkix-jdk18on, bcpg-jdk18on, bctls-jdk18on are all at version 1.77 or earlier.
• shiro-core, shiro-web, and any other transitive shiro artifacts are all at version 1.13.0 or earlier.
• A full ./mvn-env.sh clean install -DskipTests succeeds on Java 1.8 with no UnsupportedClassVersionError.
• javap -v on the resolved jars reports major version: 52 or 53 (Java 8 / 9 bytecode).

Out of scope

• Closing the CVEs that come back from the downgrade. Those are tracked in the parent epic.
• The deeper question of whether the project should move to Java 11+; that is also a parent-epic concern.

References

• Full analysis: docs/ai-generated/tasks/PR#-DependencyVulnerabilityAnalysis/main-vulnerability-report.md — search for "bytecode mismatch" and "Java 11 bytecode".
• Verification: any Maven Central jar's bytecode level can be checked with unzip -l <jar> | awk '/\.class$/{print $4; exit}' to find a class, then javap -v.
• BC release notes: https://www.bouncycastle.org/releasenotes.html — the 1.78 release (2024-09) explicitly switched bcprov-jdk18on to Java 11 bytecode.
• Shiro 2.0 release notes: https://shiro.apache.org/news.html — 2.0 is the first version that requires Java 11.

[natechadwick-intsof]

I think this needs updated so that we are using the JDK1.5 - JDK 1.8 version of the bc jars so that the security updates can be pulled in. The JDK 1.8+ multi platform version seems like > 1.8 rather than +1.8

[natechadwick-intsof]

Superseded by #77 for the BouncyCastle half of this bug: the artifact line has been migrated from bc*-jdk18on (Java 9/11 bytecode) to bc*-jdk15to18 (Java 5 bytecode), which is the correct long-term fix and picks up all 1.78+ CVE fixes.

The Shiro half of this bug (shiro-web 2.1.0 → 1.13.0 in modules/shindig-uber/pom.xml) is not addressed by #77 and needs a separate fix. Flagging for follow-up — please open a new issue for the Shiro pin if one doesn't exist already.

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