PropertiesLauncher fails to load PBKDF-OpenSSL of bcprov-jdk15on-1.64.jar #23165
Comments
spring-projects-issues
added
the
status: waiting-for-triage
That will depend on how you have created and configured the |
wilkinsona
added
the
status: waiting-for-feedback
|
Hi Andy, Thanks for your prompt response and beautify my initial post. Please clone my reproduction code from this repo and refer to the Readme document if needed: https://github.com/ziqianggeoffreychen/spring-boot-properties-launcher-with-broken-bcp |
spring-projects-issues
added
status: feedback-provided
|
Thanks for the sample, @ziqianggeoffreychen. Unfortunately, it does fail for me but with a different error. This is the failure that I get when launching the application with I see the same problem when launching the application in my IDE (having removed the |
wilkinsona
added
status: waiting-for-feedback
|
Hi @wilkinsona, I have git clone the code in Linux (RHEL 7.6) and get the same error. I will find a macOS to verify if the result will change. At the same time, I would like to know your Java version. I am using Oracle JDK 1.8.0. On Windows 10, it is 1.8.0_251, while on RHEL it is 1.8.0_241. If it is caused by compatible issue between macOS and Windows, I will figure out a way to generate the PEM files from scratch. Thanks and regards. |
spring-projects-issues
added
status: feedback-provided
|
I verified macOS (10.14.6), and reproduced the issue. The point here is Java version should be 1.8.0. I used maven 3.6.3 but I guess that's not the key factor. @wilkinsona, I updated the project to compare ZIP and JAR layout: ZIP layout (PropertiesLauncher) results in NoSuchAlgorithmException, on the other hand, JAR layout (JarLauncher) is normal. Could you git pull and try again? Thanks. |
|
Thanks for the updates, @ziqianggeoffreychen. Unfortunately, I'm still unable to reproduce the problem. I'm using Java 8: The application runs successfully: |
|
I've just tried in a Windows 10 VM and it works there too. Unfortunately, I don't think we're going to be able to make any progress on this one without a sample that reproduces the problem. |
wilkinsona
added
status: waiting-for-feedback
|
@wilkinsona I realized that you are using OpenJDK while I am using Oracle JDK. Could you try Oracle JDK 1.8.0_251/261? I will try OpenJDK 1.8.0_252 as well. Thanks. |
spring-projects-issues
added
status: feedback-provided
|
I confirm that when I change to OpenJDK, the issue disappears. Could you consider fully support on Oracle JDK? Our production is running on Oracle JDK. Thank you. |
|
I've just tried with 1.8.0_261 from Oracle and have been able to reproduce the problem. I'll see if I can figure out why it behaves differently, but you may need to raise this with Oracle given that their JVM's behaviour has diverged from the behaviour of the OpenJDK upon which it is based. |
|
That's great! I also changed Spring Boot version to 2.3.3-RELEASE, v2.3.0.RELEASE, no difference. But when I downgrade it to v2.2.9.RELEASE (the nearest version to v2.3), the NoSuchAlgorithmException disappears. So I guess it is not an issue of Oracle JDK. Could you have a try and compare? Thanks. |
|
The problem occurs with 2.3.0.RC1 but does not occur with 2.3.0.M4. #21072 seems to be the most likely culprit for that, however I don't yet understand the difference in behaviour between |
wilkinsona
added
type: regression
|
Here's a minimal reproduction of the problem: package com.example;
import java.io.IOException;
import java.net.JarURLConnection;
import java.net.URL;
import java.security.cert.Certificate;
import java.util.Arrays;
import org.bouncycastle.jce.provider.BouncyCastleProvider;
public class Gh23165Application {
public static void main(String[] args) throws IOException {
URL location = BouncyCastleProvider.class.getProtectionDomain().getCodeSource().getLocation();
JarURLConnection connection = (JarURLConnection)location.openConnection();
Certificate[] certificates = connection.getJarFile().getJarEntry("org/bouncycastle/jce/provider/BouncyCastleProvider.class").getCertificates();
System.out.println(Arrays.toString(certificates));
}
}A dependency on Using |
|
The failure occurs even earlier with 2.3.4 snapshots, happening when an attempt is made to load the application's main class: |
|
The behaviour difference with This doesn't happen with The close was added in ad72f86 but I can't tell why. |
wilkinsona
added
the
for: team-attention
|
I wrote that polish commit, but I'm not sure why close was called explicitly. This might be related to #17126, but I'm having a hard time finding where we actually closed the archives in 2.2. |
|
Hi @wilkinsona @philwebb , I added below tracing code to locate the root cause: The JarFile for bcprov is instantiated once and then quickly closed by the above mentioned code archive.close(). The following JarFile instances are all based upon the very first instance as the parent thus share the same JarFileEntries collection. Within the JarFileEntries instance, the very first instance is associated as the back reference but it has been explicitly closed by archive.close(). Whenever this kind of new JarFile's entry is accessed, the real JarFile will be its closed parent rather than the new instance itself. Eventually we get "zip file closed" illegal state exception. IDE step by step trace will be helpful to show the inconsistency between newly opened JarFile instance and the closed JarFile instance referenced by its JarFileEntries member. Below highlighted related logs: |
|
Hi @wilkinsona @philwebb , in my humble opinion, the fix is to stop share JarFileEntries with its parent, which means new JarFileEntries every time. The JarFileEntries is just some indexes, not a big deal to have many copies of them. |
philwebb
removed
the
for: team-attention
|
Hi @wilkinsona @philwebb , hope you are doing well. I verified below code delta can fix the issue. Could you review and evaluate the feasibility? Thanks. |
|
The for the suggestion, but I don't think that's the right way for fix this one. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Spring Boot version: 2.3.1.RELEASE
The bouncy castle jar is embedded into spring boot fat jar, while JarLauncher can load the exactly same PBKDF-OpenSSL algorithm, PropertiesLauncher fails to load. Below is the exception:
After troubleshooting into javax.crypto.SecretKeyFactory, below eaten exception is identified as the root cause:
spring-boot/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/jar/JarFile.java
Lines 363 to 367 in 8464cfb
Why would it behave differently between JarLauncher and PropertiesLauncher on this SecretKeyFactory?
Full "zip file closed" exception stack trace by IntelliJ IDEA:
The text was updated successfully, but these errors were encountered: