Upgrade to Java 17

[netomi]

Currently the webservices use java 11 for deployment due to

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2612
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2604#note_1078636

we need to investigate if this can be resolved and upgrade to Java 17.

[fredg02]

Eclipse Platform switched to JDK17 in Eclipse IDE 2022-06

https://www.eclipse.org/lists/platform-dev/msg03746.html

When can/should we stop to support the signing infrastructure for Eclipse IDEs before 2022-06?

@akurtakov @merks any comments?

[merks]

It’s not clear to me how signing infrastructure relates to the IDE in which the signed content is to be used. Certainly EMF’s builds produce content that can run in indigo. I guess this is about algorithms that would not be recognized by old JVMs?

[fredg02]

I guess this is about algorithms that would not be recognized by old JVMs?

Exactly. As seen in the tickets mentioned above, signature algorithm SHA384withSHA384withRSA is not supported in JDK 11, for example.

[netomi]

Actually, the deployment seems to install java 11 (see https://github.com/eclipse-cbi/org.eclipse.cbi/blob/main/webservice/deployment.libsonnet#L211), while the base image is eclipse-temurin:17-jdk, and inspecting the runtime logs shows that java 17 is used to run the webservices.

This needs to be clarified and the project cleaned to make it clear which java version to use.

[netomi]

Output from a production pod for the authenticode signing:

VM settings:
Max. Heap Size: 512.00M
Using VM: OpenJDK 64-Bit Server VM
openjdk version "17.0.6" 2023-01-17
OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10)
OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode, sharing)

2023-09-11 20:36:34 INFO  Server:384 - jetty-11.0.13; built: 2022-12-07T20:47:15.149Z; git: a04bd1ccf844cf9bebc12129335d7493111cbff6; jvm 17.0.6+10

[netomi]

so it seems in the Dockerfile we install temurin-11 for nothing as it will not be used.

[merks]

So would it no longer be possible to configure the signer to sign something such that it would still work with Java 11? It seems some of the Java 17 stuff gets back-ported to Java 11, e.g., Java 11 stopped accepting/recognizing certain weak signatures at some point too...

[netomi]

While trying to do a deployment for the authenticode signing service, we encountered a problem which made us think that its related to the used jdk version, however it was merely a build problem.

All services use a Java 17 environment to run. The jarsigner service also uses Java 17 to run, however it signs with an external program from an additionally installed JDK 11.

So, we can just clean up the build and deployment to support Java 17. Everything will work as before.

[merks]

So don't worry, be happy. 😁

[fredg02]

so it seems in the Dockerfile we install temurin-11 for nothing as it will not be used.

Just to confirm, it's not installed for nothing. Jarsigner is using it, as defined in webservice/signing/jar/jarsigner.libsonnet:

jarsigner.bin=/opt/java/openjdk11/bin/jarsigner

See here: bd592e5#diff-fd355b0c8e391aeaee0840de31e3c489d1889fbf70f35cd221c0a0327363fcffL83

[fredg02]

So we still need to discuss how long we have to keep this hacky workaround in place.

Related to that, I'd like to find out where the "SHA384withSHA384withRSA" signature algorithm name came from. Searching on the net only points back to the issues that have been reported to us.

[netomi]

so it seems in the Dockerfile we install temurin-11 for nothing as it will not be used.

Just to confirm, it's not installed for nothing. Jarsigner is using it, as defined in webservice/signing/jar/jarsigner.libsonnet:

jarsigner.bin=/opt/java/openjdk11/bin/jarsigner

See here: bd592e5#diff-fd355b0c8e391aeaee0840de31e3c489d1889fbf70f35cd221c0a0327363fcffL83

yeah, I figured that out already, was a bit hidden in the application configuration.

[netomi]

I believe the name "SHA384withSHA384withRSA" is a red herring. The actual problem is that the algorithm with id "1.2.840.113549.1.1.12" is not available on older java versions. There are other issues about that as well:

• https://bugs.eclipse.org/bugs/show_bug.cgi?id=572034

One option might be to disable the SHA384 hashing algorithm globally like explained here:

https://docs.oracle.com/en/applications/jd-edwards/administration/9.2.x/eotsc/disabling-weak-cipher-suites-globally-through-java.html#u30144032

or

https://www.java.com/en/configure_crypto.html

We could try if disabling that hashing algorithm is sufficient to generate signed jars that can be verified by older java installations.

[netomi]

well, why difficult if the solution could be simple. Right now, the jar signing service uses the default hashing and signature algorithm as defined by the java runtime. However, we could easily override that with e.g. SHA256.

Edit: actually the jarsigner already supports to specify the used algorithms in the request, if none are specified the default will be used.

https://github.com/eclipse-cbi/org.eclipse.cbi/blob/main/webservice/signing/jar/src/main/java/org/eclipse/cbi/webservice/signing/jar/SigningServlet.java#L78-L98

[fredg02]

well, why difficult if the solution could be simple. Right now, the jar signing service uses the default hashing and signature algorithm as defined by the java runtime. However, we could easily override that with e.g. SHA256.

Edit: actually the jarsigner already supports to specify the used algorithms in the request, if none are specified the default will be used.

We already suggested that here https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2604#note_1076184, but it did not seem to help.

[netomi]

well if you suggest to use SHA384withRSA as signature algorithm you get exactly that. But this is the algorithm that we want to avoid as it does not seem to be available on older java versions.

and we need to test what really happens in the service, maybe the request is not setting the algorithms correctly.

well I can test for sure what happens with java 17 and which algorithms is used and try to set a different one, e.g. the one from previous versions.

[fredg02]

well if you suggest to use SHA384withRSA as signature algorithm you get exactly that. But this is the algorithm that we want to avoid as it does not seem to be available on older java versions.

It seemed like we go different results from JDK17 vs JDK11 when specifying "SHA384withRSA".

+1 for more testing.

[netomi]

so I did try to sign with Java 17 and compare with previous Java versions. No matter what you specify as sigalg, it is always added in a way that looks strange on older JDKs (SHA384with<sigalg>).

An explanation can be found in this very informative blog post: https://adangel.org/2022/03/05/sha256withrsa-jarsigner/

so apparently the code of the jarsigner has changed in jdk 17 to prepend some info to the signature algorithm. This only makes problems with eclipse equinox as it used to have its own verification mechanism that did not support that. Should be fixed in v4.20 released in 2021.

Sofar I did not find a way around. At some point it might be acceptable to switch to Java 17 as all eclipse installations in the wild will support the new signature algo name.

So we should probably keep the way to use a JDK 11 to sign for the time being and switch when versions of Eclipse prior to 4.20 have more or less reached their EOL if this exists for the platform at all?

[netomi]

actually a workaround could be to use ProGuard which is also able to sign jar files :D (Disclaimer: I worked on ProGuard in the past).

[netomi]

The functionality to sign jar files is now in a proguard-core library that is under Apache 2 License:

https://github.com/Guardsquare/proguard-core/blob/master/base/src/main/java/proguard/io/SignedJarWriter.java

I will work on a PR to showcase.

[netomi]

I managed to come up with something that results in the same as running jarsigner using proguard-core. However, this involved quite some modifications as proguard-core currently does not support including timestamp data received from a timestamp authority. Will try to get this into upstream. Furthermore, proguard-core changes the modification time of all entries in a jar file which certainly is not what you want in a jarsign mode, this will need to be changed for such a use-case as well.

[netomi]

Created PR Guardsquare/proguard-core#121 on proguard-core upstream repo to support passing through the modification time when signing a jar file. Also adding an example how the library can be used as a replacement for the jarsigner command line tool.

[akurtakov]

I kind of lost track what (if anything) is to be done/discussed here?

[netomi]

We had the wrong assumption that the different webservices are deployed using Java 11 thus we were looking into ways to upgrade to Java 17 as a whole. However, this assumption was wrong and the webservices are deployed and run with Java 17, only for jarsigning, an additional Java 11 JRE / JDK is installed in the container to do jarsigning in a way that is supported with older Eclipse versions.

Now from my POV the currently used workaround (the additional Java 11 runtime) is acceptable and it does not really make sense to look into alternatives. I investigated if proguard-core could be used as a replacement for jarsigner, but some non-trivial work would have to be done to support that in a way that would really be a replacement for jarsigner.

Thus no action is planned from my side for now, at some point we could remove the Java 11 workaround but I learned that some companies keep using very old Eclipse versions, so that might not be doable in the near future.

[akurtakov]

Closing the issue as per previous comment.