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.