• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • core
    • None
    • 2.358

      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.

       

       

          [JENKINS-67950] Log4jHotPatch signer error

          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.

          Kalle Niemitalo added a comment - 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.

          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.

          Kalle Niemitalo added a comment - 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.

          Basil Crow added a comment -

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

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

          Basil Crow added a comment -

          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.

          Basil Crow added a comment - 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.

          Dave added a comment -

          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)

          Dave added a comment - 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)

          Dave added a comment -

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

          Dave added a comment - Is it likely that this error does not affect the running of Jenkins?

          Basil Crow added a comment -

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

          This error does not affect the running of Jenkins.

          Basil Crow added a comment - Is it likely that this error does not affect the running of Jenkins? This error does not affect the running of Jenkins.

          Dave added a comment -

          Thanks Basil.

          Dave added a comment - Thanks Basil.

          Basil Crow added a comment -

          We added a workaround for this upstream issue in 2.358.

          Basil Crow added a comment - We added a workaround for this upstream issue in 2.358.

            Unassigned Unassigned
            drdavew Dave
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: