[JENKINS-67950] Log4jHotPatch signer error

[timja]

I see the following error message in the Jenkins logs:

java.lang.SecurityException: class "Log4jHotPatch"'s signer information does not match signer information of other classes in the same packagejava.lang.SecurityException: class "Log4jHotPatch"'s signer information does not match signer information of other classes in the same package at java.lang.ClassLoader.checkCerts(ClassLoader.java:891) at java.lang.ClassLoader.preDefineClass(ClassLoader.java:661) at java.lang.ClassLoader.defineClass(ClassLoader.java:754) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:473) at java.net.URLClassLoader.access$100(URLClassLoader.java:74) at java.net.URLClassLoader$1.run(URLClassLoader.java:369) at java.net.URLClassLoader$1.run(URLClassLoader.java:363) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:362) at java.lang.ClassLoader.loadClass(ClassLoader.java:418) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352) at java.lang.ClassLoader.loadClass(ClassLoader.java:351) at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:304) at sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:411)

 

I have seen this on version 2.337 and 2.332. On the 2.337 server the Jenkins logs are going to /var/log/messages and not to /var/log/jenkins/

This does not stop the server being built or operating.

 

 

---

Originally reported by drdavew, imported from: Log4jHotPatch signer error

• status: Open
• priority: Minor
• resolution: Unresolved
• imported: 2022/01/10

[timja]

kon:

These Log4jHotPatch errors were seen in JENKINS-67900 as well, but they apparently were not the cause of the PATH problem that was reported there.

[timja]

kon:

AWS announced Log4jHotPatch in Hotpatch for Apache Log4j (2021-12-12). Amazon Linux Hotpatch Announcement for Apache Log4j (2021-12-14) says JDKs in Amazon Linux install Log4jHotPatch automatically, and describes how to disable it if necessary.

I don't know how to make Log4jHotPatch actually work with Jenkins.

[timja]

basil:

Can be reproduced locally by building Log4jHotPatch.jar and running java -Dlog4jFixerVerbose=true -cp Log4jHotPatch.jar Log4jHotPatch ${JENKINS_PID}.

[timja]

basil:

Stepping through the problematic frames in the debugger, I do not think Jenkins is at fault here. Jenkins contains some classes in the unnamed package namespace:

$ jar tf jenkins.war
[…]
ColorFormatter.class
JNLPMain.class
LogFileOutputStream$1.class
LogFileOutputStream.class
Main$FileAndDescription.class
Main.class
MainDialog.class
[…]
META-INF/JENKINS.RSA
META-INF/JENKINS.SF
META-INF/MANIFEST.MF
[…]
$

Note that META-INF/JENKINS.RSA and META-INF/JENKINS.SF are only present in our signed official releases; a local build will not contain these. The presence of these classes and signatures means that the system class loader associates the signatures with the unnamed package namespace. Then, when Log4jHotPatch attempts to load a class into the same unnamed package namespace without a signature, class loading fails.

I do not think Log4jHotPatch should make any assumptions about whether or not it is free to load unsigned classes into the unnamed package namespace. Perhaps Log4jHotPatch should use its own package namespace instead. I filed corretto/hotpatch-for-apache-log4j2#53 to track this.

[timja]

JIRAUSER133903:

Thanks for all the comments so far.

Here is the Java version of the EC2 instance that has this issue:

java -version
openjdk version "1.8.0_312"
OpenJDK Runtime Environment (build 1.8.0_312-b07)
OpenJDK 64-Bit Server VM (build 25.312-b07, mixed mode)

[timja]

JIRAUSER133903:

Is it likely that this error does not affect the running of Jenkins?

[timja]

basil:

Is it likely that this error does not affect the running of Jenkins?

This error does not affect the running of Jenkins.

[timja]

JIRAUSER133903:

Thanks Basil.