bc-fips and SpringBoot 3.2 compatibility issue

[x41dev]

Hello Team

After upgrading my project to SpringBoot 3.2 app is not starting with an error: FipsOperationError: Module checksum failed: unable to find

Exception in thread "main" java.lang.reflect.InvocationTargetException
  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
  at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.base/java.lang.reflect.Method.invoke(Method.java:568)
  at org.springframework.boot.loader.launch.Launcher.launch(Launcher.java:91)
  at org.springframework.boot.loader.launch.Launcher.launch(Launcher.java:53)
  at org.springframework.boot.loader.launch.JarLauncher.main(JarLauncher.java:58)
Caused by: org.bouncycastle.crypto.fips.FipsOperationError: Module checksum failed: unable to find
  at org.bouncycastle.crypto.fips.FipsStatus.checksumValidate(Unknown Source)
  at org.bouncycastle.crypto.CryptoServicesRegistrar.getDefaultMode(Unknown Source)
  at org.bouncycastle.crypto.CryptoServicesRegistrar.<clinit>(Unknown Source)
  at org.bouncycastle.jcajce.provider.ProvSecureHash$MD5.configure(Unknown Source)
  at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.<init>(Unknown Source)

BC Provider is added during app startup Security.insertProviderAt(new BouncyCastleFipsProvider(), 1);

After some analysis I found a root cause

• SB 3.2 introduced Nested Jar Support which changes URL format:

The previous URL format of jar:file:/dir/myjar.jar:BOOT-INF/lib/nested.jar!/com/example/MyClass.class has been replaced with jar:nested:/dir/myjar.jar/!BOOT-INF/lib/nested.jar!/com/example/MyClass.class

• org.bouncycastle.crypto.fips.FipsStatus#getResourceName has hardcoded marker.startsWith("jar:file:") && marker.contains("!/") so method returns null to the caller org.bouncycastle.crypto.fips.FipsStatus#checksumValidate and mentioned exception is raised

workaround: use SB loader fallback option

• gradle:

bootJar {
  loaderImplementation = org.springframework.boot.loader.tools.LoaderImplementation.CLASSIC
}

• maven

<build>
  <plugins>
    <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
        <executions>
          <execution>
            <goals>
              <goal>repackage</goal>
            </goals>
            <configuration>
              <loaderImplementation>CLASSIC</loaderImplementation>
            </configuration>
          </execution>
        </executions>
    </plugin>
  </plugins>
</build>

[dghgit]

The bc-fips jars can't be tampered with or repackaged. This indicates one of those things has probably happened.

[x41dev]

In this case I repackage my app because I want to create fat jar with all dependencies inside. bc-fips jar is untouched under my-app.jar!/BOOT-INF/lib/bc-fips-1.0.2.4.jar

org.bouncycastle.crypto.fips.FipsStatus#getMarker returns:

• jar:file:my-app.jar!/BOOT-INF/lib/bc-fips-1.0.2.4.jar!/ - in SB3.1.x
• jar:nested:my-app.jar/!BOOT-INF/lib/bc-fips-1.0.2.4.jar!/ - in SB3.2.0

to be more specific: LICENSE.class.getProtectionDomain() .getCodeSource() uses new Springboot's classloader and returns this 'nested' substring'

IMO possible fix: adding:

else if (marker.startsWith("jar:nested:") && marker.contains("!/")){
  try{
    String jarFilename = URLDecoder.decode(marker.substring("jar:nested:".length(), marker.lastIndexOf("!/")), "UTF-8");
    result = jarFilename;
  }
  catch (IOException e){
    result = null;
  }
}

to org.bouncycastle.crypto.fips.FipsStatus#getResourceName should fix the problem without regression

[dghgit]

Ah, is that what's going on. Yes, we should be able to do that. It's likely to take a while though, I'm pretty sure a change like this would be regarded as what they call a 1SUB, but it's still going to take months to get it approved.

[nibexo]

@dghgit Looks like I have the same problem in my project Any update with this issue? Do you know when we can expect fix?

[dghgit]

We're going through the process. It will take months to be done though.

[jaymz1439]

any updates about this issue? @dghgit

[kranthirathikanti]

@dghgit

Hi, it also needs to handle marker.startsWith("vfs:") as all jboss / wildfly refers its classpath modules / libraries with vfs as protocol.

I hope your team will include this change as well.

[Skfazil]

Hey @dghgit , Good day!

I see this conversation is still open, and we are facing similar issue while trying to upgrade to SB 3.2. Is there any solution defined yet. If not, any ETA's that is discussed at the moment?

Please do let us know.

[dghgit]

1.0.2.5 is now available on Maven Central and the BC website. Note: certification is still in progress for this module, however we believe it should fix this issue. Let us know if it does.