fix: HSM configure_hsm.sh fails on OpenJDK 21 due to removed lib/ext

[peterhaochen47]

• remove code that relies on old of date JVM:

  • The removed code even has comment saying so: "JVM 8 - WILL NOT WORK ON JVM 11"

• The Java Extension Mechanism (lib/ext directory) was permanently removed in JEP 220 (Java 9). The configure_hsm.sh script was copying Luna HSM JSP libraries to $JAVA_HOME/lib/ext/, causing the pre-start hook to crash on the current openjdk_21.0 stemcell.

• Remove the broken cp commands and instead set java.library.path via JAVA_TOOL_OPTIONS so the Luna native library is discoverable when an HSM encryption provider is configured.

  • for native .so loading — this is the standard Luna/PKCS#11 pattern on JDK 9+.

TNZ-112110
ai-assisted=yes

[hsinn0]

What about /var/vcap/packages/luna-hsm-client-7.4/jsp/ (for LunaProvider.jar)? Do we not need to do something about it?

[hsinn0]

Cursor/Auto's analysis on LunaProvider.jar:

Source: LunaProvider.jar ships inside the luna-hsm-client-7.4 BOSH package — it is extracted from the SafeNet/Thales Luna client RPMs by scripts/convert-luna-client-to-bosh-package and ends up at:

/var/vcap/packages/luna-hsm-client-7.4/jsp/LunaProvider.jar ← Java provider
/var/vcap/packages/luna-hsm-client-7.4/jsp/64/libLunaAPI.so ← native library
Why it matters: LunaConnection.java loads the provider entirely through reflection at runtime:

LunaConnection.java
Lines 29-31
provider = (Provider) Class.forName("com.safenetinc.luna.provider.LunaProvider")
.getDeclaredConstructor().newInstance();
Security.addProvider(provider);
Because it uses Class.forName(), the JVM must find LunaProvider.jar on the classpath at runtime — there is no compile-time dependency, and it is not listed in build.gradle, so it is not bundled inside credhub.jar.

The old approach (removed by this commit): copy both LunaProvider.jar and libLunaAPI.so into $JAVA_HOME/lib/ext/, which JDK 8's extension mechanism auto-loaded onto the classpath.

The new approach (this commit): only sets -Djava.library.path for the .so. The native library is now discoverable, but LunaProvider.jar has no path to the classloader.

The critical problem: Both credhub.erb and ctl.erb launch with java -jar credhub.jar. When -jar is used, the JVM ignores the CLASSPATH environment variable and any -cp flag — only the JAR's own MANIFEST.MF Class-Path is honoured. Since LunaProvider.jar is not in that manifest, Class.forName("com.safenetinc.luna.provider.LunaProvider") will throw a ClassNotFoundException at runtime, crashing the HSM connection on startup.

The fix needs an additional line alongside -Djava.library.path, for example using Spring Boot's loader.path system property:

-Dloader.path=/var/vcap/packages/luna-hsm-client-7.4/jsp/
This tells Spring Boot's LaunchedURLClassLoader to include LunaProvider.jar in the application classloader, which is the supported way to add external JARs to a Spring Boot fat-JAR application on JDK 9+.

[hsinn0]

From https://thalesdocs.com/dpod/services/luna_cloud_hsm/extern/client_guides/Content/sdk/java/jsp_overview_install.htm

To configure Java 9+ for Luna JSP

Add LunaProvider.jar to the Java classpath and specify the Luna Java library location (libLunaAPI.so in Unix based systems or LunaAPI.dll in Windows systems) in the Java library path.

For example:

java -cp /<directory_location>/LunaProvider.jar -Djava.library.path=<Luna_Java_library_location>