fix: pin BouncyCastle and Shiro to Java 8-compatible versions

[VedantMadane]

Summary

Fixes #74.

The root POM targets JDK 1.8, but two dependency lines resolve artifacts compiled as Java 11 bytecode (class major version 55). That is inconsistent with <jdk>1.8</jdk> / <java.source>1.8</java.source> and can cause UnsupportedClassVersionError on a true Java 8 runtime.

Changes

Coordinate	Was	Now	Rationale
org.bouncycastle:bc*-jdk18on via ${bc.version}	1.83	1.77	1.78+ jdk18on line is Java 11 bytecode
org.apache.shiro:shiro-web (modules/shindig-uber)	2.1.0	1.13.0	Shiro 2.0+ requires Java 11; 1.13.0 is Java 8

BC artifacts managed through ${bc.version} in root dependencyManagement (bcmail, bcpg, bcpkix, bcprov, bctls jdk18on) all move together. Shiro is only declared directly in modules/shindig-uber/pom.xml.

Note on security

Downgrading BC 1.83 → 1.77 may re-introduce CVEs fixed in 1.78+. That trade-off is called out in #74 / the parent epic; this PR only restores Java 8 honesty of the POM.

Test plan

• Property / version pins match the issue acceptance criteria
• ./mvn-env.sh clean install -DskipTests on Java 8 (full reactor; not run in this environment)
• javap -v on resolved jars reports major version 52 or 53 (not 55)

Signed-off-by: Vedant Madane 6527493+VedantMadane@users.noreply.github.com

[natechadwick-intsof]

Code review

Two nitpicks, both optional:

1. Could you actually run ./mvn-env.sh clean install -DskipTests on a Java 8 JDK and javap -v on the resolved BC/Shiro jars, then tick the remaining two boxes in the test plan? That's the only acceptance-criteria item in #74 that this PR hasn't yet demonstrated end-to-end on a real Java 8 reactor.

2. Tiny readability improvement: add a one-line comment above each new version pin explaining why 1.77 / 1.13.0 (e.g. <!-- 1.78+ switched to Java 11 bytecode (major 55) — see #74. Last Java-8-compatible jdk18on line. -->). Saves the next person a re-derivation.

Consider also: add a <shiro.version> property in the root POM and a dependencyManagement entry for shiro-web, so any future module that adds a Shiro dep cannot drift. Not a blocker.

---

Out-of-PR observation — please look at .github/dependabot.yml before merging:

The dependabot config fully-ignores Shiro (org.apache.shiro* → "freeze automated bumps; 2.x is Java 11 bytecode"). Good. But BouncyCastle has no entry at all — not in the java8-safe-patches exclude list, not in the java8-security-patches exclude list, not in the ignore block. That means as soon as this PR lands, the next weekly Dependabot run is free to propose org.bouncycastle:bc*-jdk18on:1.83+ (or any 1.78–1.85 release) and re-bundle the same Java 11 bytecode into a "patch" PR. This PR's correctness depends on Dependabot not undoing it.

Two ways to close that gap (this PR is fine either way; whichever you prefer, the gap itself is worth flagging):

a) Mirror the Shiro entry — full-ignore org.bouncycastle* with a comment ("1.78+ jdk18on line is Java 11 bytecode; freeze automated bumps; manual PRs only"). This is the strictest, matches what the PR does for Shiro, and means future BC bumps require a deliberate PR.

b) Version-range ignore — dependency-name: "org.bouncycastle*" with versions: [">= 1.78.0"]. This is more permissive: Dependabot can still propose 1.77.x patches, but not 1.78+. Probably the better default for a security library, since Dependabot's security-advisories flow will still work for 1.77.x and earlier. Pair it with the comment <!-- 1.78+ jdk18on switched to Java 11 bytecode (major 55) — see #74. -->.

I lean (b) because it keeps the security-update path alive while still blocking the regression. But this is a Dependabot-config change, not strictly part of this PR; the cleanest sequence is: merge this PR for the immediate fix, then open a follow-up issue (or a one-line Dependabot PR) to add the BC entry.

---

Otherwise: correct scope, correct direction, security trade-off is openly acknowledged, and the surgical pom edits move the right five BC artifacts in lockstep via the single ${bc.version} property. Approving. Nice work.

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

[natechadwick-intsof]

@VedantMadane Can you amend your commit to be GPG signed?

[natechadwick-intsof]

Superseded by #77, which switches to the correct artifact line (bc*-jdk15to18, Java 5 bytecode) instead of pinning the misleading bc*-jdk18on 1.83 → 1.77. #77 keeps the project on the current BC line with all 1.78+ CVE fixes and avoids re-introducing the CVEs that #75's downgrade would have. Closing as superseded.

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