Signer information does not match

D

7

25

I'm receiving the following error on log file.

(java.lang.SecurityException: class "com.adventnet.snmp.snmp2.SecurityModelTable"'s signer information does not match signer information of other classes in the same package thrown

The thing is when I run the below command, it says the jar is verified.

/usr/jdk/instances/jdk1.5.0/bin/jarsigner -verify -verbose Jarfile.jar

If the jar file is verified then how can this problem occur?

Durfee answered 16/1, 2012 at 9:39 Comment(0)

P

24

It means that you have two or more classes in the same package with different signature data. Usually that means the classes come from different JARs, one of which is signed and the other is unsigned.

Prudhoe answered 16/1, 2012 at 9:42 Comment(12)

But how can this jar is verified then ? Shouldn t it fail the verification ? – Durfee 16/1, 2012 at 9:43

@mibzer: No, that's a different kind of verification. Jarsigner only verifies that particular JAR. The Java runtime works with many JARs and checks whether they are compatible. If it allowed code from a different source in the same package as a signed JAR, it would weaken the security guarantees implied by the signature. – Prudhoe 16/1, 2012 at 10:6

So you mean that, some other jar files my contain same class, doing some work but different signature data. And that cause a security issue and exception thrown right ? – Durfee 16/1, 2012 at 10:12

There's quite possibly two versions of the jar being loaded. Possibly one is in a parent class loader of the other (say, one in a common library area and one in the application). – Mantua 16/1, 2012 at 10:14

@mibzer: Basically yes. But as the exception says, it can be any class in the same pacakge, and it may be in a folder structure rather than a JAR. And that class may have no signature at all rather than a different one. – Prudhoe 16/1, 2012 at 10:17

That is really interesting, thanks much. I guess I will grep and try to find which file or directory is containing related class. – Durfee 16/1, 2012 at 10:26

@Michael Borgwardt, I still have problem, actually I grepped all file system and didnt found other classes. I will be appreciated if you have a solution. – Durfee 16/1, 2012 at 20:33

@mibzer: Just an idea: you could run the application in debug mode and put a breakpoint in the constructor of java.lang.SecurityException, then look through the variables throughout the stack to find out where the colliding classes are defined. – Prudhoe 16/1, 2012 at 20:45

@Michael, that would be really great but actually I dont have permission to run or debug code :( . Application is running on server system. And I am trying to resolve problem by editing configurations. – Durfee 16/1, 2012 at 21:32

@mibzer: well, I'm out of ideas. Double-check if you've looked everywhere for classes in the com.adventnet.snmp.snmp2 package - I'm not sure that grepping for them will find them inside JARs. – Prudhoe 17/1, 2012 at 8:20

@MichaelBorgwardt we have finally resolved the issue. There was an expired jar file which loaded to classpath. Actually this file was belong to earlier version of our software. But we dont how it stayed there. Thanks for you replies. – Durfee 25/1, 2012 at 23:56

This thread helped me track down my instance of this problem: #11577579. – Palladino 4/10, 2012 at 7:0

H

25

Check the pom dependency tree for same packages of different versions.

I had this issue with itext-2.1.7 including old bouncycastle's bcpkix that was included in a later version elsewhere.

Use this pattern:

<dependency>
  package X
  <exclusions>
    <exclusion>
      old package Y
    </exclusion>
  </exclusions>
</dependency>

<dependency>
  latest package Y
</dependency>

Update: To check the dependency tree details of package_Y you can use mvn dependency:tree -Dverbose -Dincludes=package_Y. For more info check maven documentation on resolving dependency tree problems. Also Eclipse has quite a nice dependency tree viewer.

Hyperthyroidism answered 22/3, 2013 at 10:27 Comment(0)