Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jar signing limit size vs jdk.jar.maxSignatureFileSize #870

Closed
schedin opened this issue Aug 14, 2023 · 2 comments
Closed

Jar signing limit size vs jdk.jar.maxSignatureFileSize #870

schedin opened this issue Aug 14, 2023 · 2 comments

Comments

@schedin
Copy link

schedin commented Aug 14, 2023

Question

In the release notes of Java 17.0.8 on https://www.oracle.com/java/technologies/javase/17-0-8-relnotes.html#R17_0_8: I find:

New System Property to Control the Maximum Size of Signature Files (JDK-8300596 (not public))

A new system property, jdk.jar.maxSignatureFileSize, has been added to allow applications to control the maximum size of signature files in a signed JAR. The value of the system property is the desired size in bytes. The default value is 8000000 bytes.

I have a system with a signed jar file that contains a lot of classes. Because of the security feature implemented in JDK-8300596 I now get this error message when starting java with this jar file on the CLASSPATH:

Error occurred during initialization of boot layer
java.lang.module.FindException: java.io.IOException: Unsupported size: 9853735 for JarEntry META-INF/MANIFEST.MF. Allowed max size: 8000000 bytes

The META-INF/MANIFEST.MF inside my jar-file is indeed 9853735 bytes big (because of signing and many classes)!

I have servers running Java in systemd services and I am now looking for options to handle this. I would like to configure the JDK installation to always set the jdk.jar.maxSignatureFileSize (globally on my server). But I have not find any way of configuring Temurin to do this. I have tried to edit the files in /usr/lib/jvm/temurin-17-jdk/conf to squeeze this option in, but so far I have been unsuccessful.

The best I have found so far is to create the file /etc/systemd/system.conf.d/jdk_java_options.conf with the contents:

[Manager]
DefaultEnvironment="JDK_JAVA_OPTIONS=-Djdk.jar.maxSignatureFileSize=20000000"

I find the ticket https://bugs.openjdk.org/browse/JDK-8312489 and see I’m not the only one with this problem. It looks like in Java version 22 the default value will be increased to 16000000 bytes. But I don’t see any indication this this ticket will be backported into Java 17.

Does anyone know any other workarounds?

Context

Java version:

# java -version
openjdk version "17.0.8" 2023-07-18
OpenJDK Runtime Environment Temurin-17.0.8+7 (build 17.0.8+7)
OpenJDK 64-Bit Server VM Temurin-17.0.8+7 (build 17.0.8+7, mixed mode, sharing)

Temurin is installed via RPM from https://packages.adoptium.net/ui/native/rpm/centos/7/x86_64/Packages/

Your operating system and platform:

Linux x86_64 arch. Mostly CentOS 7 / RHEL 7. But also some Alma 9 / RHEL 9. Both VMs (Openstack/VMware) and hardware (mostly HPE Gen 10/11 servers). Some containers that don't use Temurin, instead they use Red Hat ubi8/openjdk-17-runtime.

@karianna
Copy link
Contributor

@schedin your workaround to edit /etc/systemd/system.conf.d/jdk_java_options.conf is the best way forward presently. Once the fix is in upstream, folks may choose to back port it to 21 and 17. I'd recommend adding a comment requesting that.

@schedin
Copy link
Author

schedin commented Aug 20, 2023

Thanks for the update/confirmation!

I'm not an OpenJDK developer so I cannot comment on https://bugs.openjdk.org/browse/JDK-8312489. I have however asked a company, that I have commercial support with, to influence that this gets backported. Their guess is that this will be backported into 8, 11, 17 and 21 and that will happen in normal quarterly update for release in October.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants