信息不匹配

我像往常一样重新编译了我的类，然后突然收到了下面的错误消息。为什么? 我该如何修复它？

java.lang.SecurityException: class "Chinese_English_Dictionary"'s signer information does not match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(ClassLoader.java:776)
247153 次浏览
小开
最佳答案

当属于同一个包的类从不同的 JAR 文件中加载时，这种情况就会发生，而且这些 JAR 文件的签名使用不同的证书签名——或者，也许更常见的情况是，至少有一个证书被签名，而其他一个或多个证书没有签名(这包括从目录中加载的类，因为那些 AFAIK 无法被签名)。

因此，要么确保所有 JAR (或者至少包含来自相同包的类的 JAR)都使用相同的证书进行签名，要么从具有重叠包的 JAR 文件的清单中删除签名。

小开

解决这个问题的一个简单方法是尝试更改您导入的 jar 文件的顺序，这可以从(Eclipse)中完成。右键单击您的包-> 构建路径-> 配置构建路径-> 引用和库-> 订单和导出。尝试更改包含签名文件的 jar 的顺序。

小开

由于 CGLIB 使用自己的签名者信息而不是应用程序目标类的签名者信息，因此在使用 CGLIB 插装的代理时可能会出现这种情况。

小开
  1. 签名后，访问: dist lib
  2. 找到多余的罐子
  3. 使用 Winrar，解压缩一个文件夹(解压缩到“文件夹名称”)选项
  4. 访问: META-INF/MANIFEST.MF
  5. 像这样删除每个签名:

名称: net/sf/Jasperreports/engine/util/xml/JaxenXPathExecterFactory.c 姑娘 SHA-256-Digest: q3B5wW + hLX/+ lP2 + L0/6wRVXRHq1mISBo1dkixT6Vxc =

  1. 保存文件
  2. 再拉上拉链
  3. 重新命名旁边的。罐回来
  4. 已经开始了
小开

如果包含一个具有不同名称或来自不同位置的文件两次，尤其是同一文件的两个不同版本，也会发生这种情况。

小开

如果你使用 Maven，一个调试发生冲突的 jar 的有用方法是:

mvn dependency:tree

例如，对于一个例外:

java.lang.SecurityException: class "javax.servlet.HttpConstraintElement"'s signer information does not match signer information of other classes in the same package

我们会:

mvn dependency:tree|grep servlet

其产出:

[INFO] +- javax.servlet:servlet-api:jar:2.5:compile
[INFO] +- javax.servlet:jstl:jar:1.2:compile
[INFO] |  +- org.eclipse.jetty.orbit:javax.servlet.jsp:jar:2.2.0.v201112011158:compile
[INFO] |  +- org.eclipse.jetty.orbit:javax.servlet.jsp.jstl:jar:1.2.0.v201105211821:compile
[INFO] |  +- org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:compile
[INFO] +- org.eclipse.jetty:jetty-servlet:jar:9.0.0.RC2:compile

显示了冲突的 servlet-api 2.5和 javax.servlet 3.0.0.x。

B.其他有用的提示(如何调试安全异常和如何排除 Mavendeps)在问题 签名者信息不匹配中。

小开

我可以修好它。

根本原因: 当使用带有签名的 jar 的 Sun JAXB 实现时，这是一个常见问题。 本质上，JAXB 实现通过生成一个类直接访问属性而不使用反射来避免反射。不幸的是，它在被访问的类的同一个包中生成了这个新类，这就是出现这个错误的原因。

决心: 添加以下系统属性以禁用与带签名的 jar 不兼容的 JAXB 优化: - Dcom.sun.xml.bind.v2.bytecode. ClassTailor.noOptimize = true

档号: https://access.redhat.com/site/solutions/42149

小开

在我的例子中，我在库路径中复制了 BouncyCastle 的 JAR 版本: S

小开

如果您在 Eclipse 中运行它，请检查添加到构建路径中的任何项目的 jar; 或者执行 control-shift-T 并扫描匹配相同名称空间的多个 jar。然后从项目的构建路径中删除多余的或过时的罐子。

小开

基于@Mohit Phougat 响应，如果您正在运行一个带有@Grab 注释的 Groovy，那么您可以尝试重新排序这些注释。

小开

在我的例子中，这是一个包名冲突。当前项目和已签名的引用库有一个共同的 package.foo.utils包。只是将当前容易出错的项目包名称更改为其他名称。

小开

有点老套，但既然我在这个问题上卡了很长时间，这里有一个解决方案(希望它能帮到某人)。

我的设想是:

包名是: com.abc.def。有两个 jar 文件包含这个包中的类，比如 jar1和 jar2，也就是说，一些类在 jar1中，另一些在 jar2中。这些 jar 文件使用相同的密钥存储库进行签名，但在构建过程中的不同时间进行签名(即单独签名)。这似乎导致 jar1和 jar2中的文件有不同的签名。

我把所有的文件放在 jar1中，然后构建(并签名)它们，问题就解决了。

PS: 包名和 jar 文件名只是示例

小开

我也有过类似的例外:

java.lang.SecurityException: class "org.hamcrest.Matchers"'s signer information does not match signer information of other classes in the same package

根本问题在于我两次使用了 Hamcrest 图书馆。一次使用 Maven pom 文件。我还在项目的构建路径中添加了 jUnit 4库(其中还包含一个 Hamcrest 库)。我只需要从构建路径中删除 JUnit，一切都很好。

小开

如果您添加了来自 bouncycastle.org 的所有 jar (在我的例子中来自 crypto-159.zip) ，那么只需删除不适用于您的 JDK 的 jar。有很多冗余。你可能只需要“ jdk15on”罐子。

小开

这个问题已经持续了很长时间，但我想投入一些东西。我一直在做一个 Spring 项目挑战，我在 EclipseIDE 中发现了这个问题。如果您正在使用 Maven 或 Gradle for Spring Boot Rest API，那么您必须删除构建路径中的 Junit 4或5，并将 Junit 包含在 pom.xml 或 Gradle 构建文件中。我猜这也适用于 yml 配置文件。

小开

这种情况在我使用 JUnit + REST Assure + Hamcrest 时发生过。在这种情况下，不要将 JUnit 添加到构建路径中。如果您有一个 Maven 项目，下面的 pom.xml 文件为我解决了这个问题:

<dependencies>


<dependency>
<groupId>io.rest-assured</groupId>
<artifactId>rest-assured</artifactId>
<version>3.0.0</version>
</dependency>


<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-all</artifactId>
<version>1.3</version>
</dependency>




<!-- https://mvnrepository.com/artifact/junit/junit -->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
</dependency>


</dependencies>
小开

我在 Eclipse 和 JUnit 5中遇到了这个问题。 我的解决方案的灵感来自用户2066936的前一个答案 它用于重新配置导入库的顺序:

  1. 右键单击该项目。
  2. 打开[ Java 构建路径]。
  3. 单击“订购和导出”。
  4. 那就把 JUNIT 推到最高优先级。
小开

我运行的是 6月5日，也引用了 Hamcrest 外部 jar，但是 Hamcrest 也是 6月5日库的一部分。因此，我将外部 Hamcrest jar 文件的顺序移动到构建路径中的 6月5日库之上。

enter image description here

小开

在尝试使用 Mockito 时，我也遇到了类似的错误:

"$$FastClassByMockitoWithCGLIB$$abb8f5a0"'s signer information does not match signer information of other classes in the same package"

我使用的是旧版本的 Mockito，升级到最新的 Mockito 版本解决了这个问题。正如在其他答复中提到的，问题出在 CGLIB。在新版本中，Mockito 用 ByteBuddy 取代了 CGLIB，这样问题就解决了。我还必须将新的 ByteBuddy jar 添加到 Eclipse 的类路径中，以使 Mockito 重新工作。


提交答案