Update BouncyCastle dependencies from jdk15to18 to jdk18on

[stephen-crawford]

Description

This change updates bouncy castle dependencies to the most recent jdk18on versions. The reason for this change is because it may fix an intermittent AEAD cipher failure experienced on cluster start.

Related Issues

• [Bug] SSLHandshakeException: Insufficient buffer remaining for AEAD cipher fragment security#3299

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Failing checks are inspected and point to the corresponding known issue(s) (See: Troubleshooting Failing Builds)
• Commits are signed per the DCO using --signoff
• Commit changes are listed out in CHANGELOG.md file (See: Changelog)
• Public documentation issue/PR created

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[github-actions]

❌ Gradle check result for c2dc38b: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[stephen-crawford]

While its good that the libraries seem compile safe; there can be hidden risks of performance regression or security robustness by switching on older platforms. Can you look into how BouncyCastle recommends these different versions?

Ideally this change would alter the dependency depending on the jdk target, using the existing bouncy castle version vs on supported platforms using jdk18on. This might be a good middle ground to unblock testing on jdk21 and in the security plugin branches.

This is the recommended BouncyCastle version. The current version we use (15to18) is meant for projects which cannot support multi-release jars.

Per the website:

Java Version Details With the arrival of Java 15. jdk15 is not quite as unambiguous as it was. The jdk18on jars are compiled to work with anything from Java 1.8 up. They are also multi-release jars so do support some features that were introduced in Java 9, Java 11, and Java 15. If you have issues with multi-release jars see the jdk15to18 release jars below.

Packaging Change (users of 1.70 or earlier): BC 1.71 changed the jdk15on jars to jdk18on so the base has now moved to Java 8. For earlier JVMs, or containers/applications that cannot cope with multi-release jars, you should now use the jdk15to18 jars.

https://www.bouncycastle.org/latest_releases.html

Seems like it should be fine @peternied

[peternied]

Thanks for the clarification @scrawfor99 - that works for me. Just waiting on passing CI and an outstanding comment

Blocking comment on the library version isn't applicable.

[github-actions]

✅ Gradle check result for 67f97c7: SUCCESS

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (8489294) 71.32% compared to head (67f97c7) 71.36%.
Report is 1 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #12317      +/-   ##
============================================
+ Coverage     71.32%   71.36%   +0.03%     
- Complexity    59764    59770       +6     
============================================
  Files          4959     4959              
  Lines        281129   281129              
  Branches      40857    40857              
============================================
+ Hits         200513   200614     +101     
+ Misses        63947    63864      -83     
+ Partials      16669    16651      -18     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[opensearch-trigger-bot]

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/OpenSearch/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch/backport-2.x
# Create a new branch
git switch --create backport/backport-12317-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 6099ed99fe68a739e60bf0c13c9954ec5c890fac
# Push it to GitHub
git push --set-upstream origin backport/backport-12317-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-12317-to-2.x.

[peternied]

@scrawfor99 Could you manually backport this change to the 2.x branch?