Migrate from *jdk15on bouncycastle packages to *jdk18on or *jdk15to18

[yeikel]

What problem are you trying to solve?

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

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.

Also

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.

Further Note (users of Oracle JVM 1.7 or earlier, users of "pre-Java 9" toolkits): As of 1.63 we have started including signed jars for "jdk15to18", if you run into issues with either signature validation in the JCE or the presence of the multi-release versions directory in the regular "jdk18on" jar files try the "jdk15to18" jars instead. Please also note the JCE certificate in the public access versions of Oracle Java 6 (6u45) and Oracle Java 7 (7u80) is expired on the 20th April 2021. We still counter sign the jdk15to18 jars with this certificate for compatibility reasons, but Oracle does distribute JVMs for Java 6 and Java 7 with a newer, and stronger, certificate to holders of Java Support Contracts.

What precondition(s) should be checked before applying this recipe?

• groupId org.bouncycastle
• artifactId *-jdk15on
• Project is using Java 8 and up

Describe the situation before applying the recipe

             <dependency>
            <groupId>org.bouncycastle</groupId>
            <artifactId>bcprov-jdk15on</artifactId>
           <version>1.70</version>
        </dependency>
        <dependency>
            <groupId>org.bouncycastle</groupId>
            <artifactId>bcpkix-jdk15on</artifactId>
           <version>1.70</version>
        </dependency>

Describe the situation after applying the recipe

diff --git a/pom.xml
index 1579251e4..2519c4a40 100644
--- a/b/pom.xml
+++ b/c/pom.xml
@@ -215,12 +215,12 @@
         <dependency>
             <groupId>org.bouncycastle</groupId>
-            <artifactId>bcprov-jdk15on</artifactId>
+            <artifactId>bcprov-jdk18on</artifactId>
-          <version>1.70</version>
+          <version>1.76</version>
         </dependency>
         <dependency>
             <groupId>org.bouncycastle</groupId>
-            <artifactId>bcpkix-jdk15on</artifactId>
+            <artifactId>bcpkix-jdk18on</artifactId>
-          <version>1.70</version>
+          <version>1.76</version>
         </dependency>
         <dependency>

Additional context

Using the *jdk15on packages puts projects at risk as this package is no longer updated with these coordinates (ie : tools like dependabot can't help here)

See :

https://nvd.nist.gov/vuln/detail/CVE-2023-33201
https://github.com/github/advisory-database/commits/main/advisories/github-reviewed/2023/07/GHSA-hr8g-6v94-x4m9/GHSA-hr8g-6v94-x4m9.json
GHSA-hr8g-6v94-x4m9

[timtebeek]

Thanks for the detailed report @yeikel ! Seems like something that could go into rewrite-migrate-java; would you agree there?
And it seems like we could achieve this with declarative yaml recipes only; would you be willing to take that on?

[yeikel]

Thanks for the detailed report @yeikel ! Seems like something that could go into rewrite-migrate-java; would you agree there?

I believe so given that Java 8 is a requirement. Do we support Java versions below 8?

And it seems like we could achieve this with declarative yaml recipes only; would you be willing to take that on?
I can give it a try. I don't think it should be that hard

The only question I have is about the version change. Should this be hardcoded to 1.76 or do we have mechanisms to pick the latest version? I assume that we could use the same 1.70 version as the security fix does not need to be part of the migration and the focus could be about the coordinate changes

[timtebeek]

Thanks for the detailed report @yeikel ! Seems like something that could go into rewrite-migrate-java; would you agree there?

I believe so given that Java 8 is a requirement. Do we support Java versions below 8?

To run OpenRewrite we require at least Java 8, but there's no reason recipes can't change code on Java 7 or even 6 I think, as much as that frightens me.

And it seems like we could achieve this with declarative yaml recipes only; would you be willing to take that on?
I can give it a try. I don't think it should be that hard

The only question I have is about the version change. Should this be hardcoded to 1.76 or do we have mechanisms to pick the latest version? I assume that we could use the same 1.70 version as the security fix does not need to be part of the migration and the focus could be about the coordinate changes

I think we can use dependency version selectors to not hard code a version, but instead pick the latest available at the time the recipe is (re)run. That should help when you run the recipe periodically as well, instead of as a one-off migration.