Java SecurityException:签名者信息不匹配
我像往常一样重新编译我的类,突然收到以下错误消息。为什么?我该如何修复它?
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)
I recompiled my classes as usual, and suddenly got the following error message. Why? How can I fix it?
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)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(21)
在 eclipse 中遇到了同样的问题,并通过以下步骤解决了这个问题。
在eclipse java build path->libraries下删除junit库并保存项目。
Faced the same issue in eclipse and Resolved this by these steps follow.
In eclipse java build path->Under libraries removed the junit library and saved the project.
根据 @Mohit Phougat 响应,如果您正在运行带有 @Grab 注释的 Groovy,您可以尝试重新排序此类注释。
Based on @Mohit Phougat response, if you are running a Groovy with @Grab annotations, you could try to re-order such annotations.
当从不同的 JAR 文件加载属于同一包的类,并且这些 JAR 文件具有使用不同证书签名的签名时,就会发生这种情况 - 或者,也许更常见的是,至少一个已签名,而其他一个或多个未签名(其中包括加载的类)来自目录,因为这些 AFAIK 无法签名)。
因此,要么确保所有 JAR(或至少包含来自相同包的类的 JAR)都使用相同的证书进行签名,要么从具有重叠包的 JAR 文件的清单中删除签名。
This happens when classes belonging to the same package are loaded from different JAR files, and those JAR files have signatures signed with different certificates - or, perhaps more often, at least one is signed and one or more others are not (which includes classes loaded from directories since those AFAIK cannot be signed).
So either make sure all JARs (or at least those which contain classes from the same packages) are signed using the same certificate, or remove the signatures from the manifest of JAR files with overlapping packages.
解决这个问题的一个简单方法是尝试更改导入的 jar 文件的顺序,这可以从(Eclipse)完成。右键单击您的包裹 ->构建路径->配置构建路径->参考文献和图书馆 ->订购和出口。尝试更改包含签名文件的 jar 的顺序。
A simple way around it is just try changing the order of your imported jar files which can be done from (Eclipse). Right click on your package -> Build Path -> Configure build path -> References and Libraries -> Order and Export. Try changing the order of jars which contain signature files.
答:如果您使用 Maven,调试冲突 jar 的一个有用方法是:
例如,对于例外:
我们这样做:
它的输出:
显示冲突的 servlet-api 2.5 和 javax.servlet 3.0.0.x。
B. 其他有用的提示(如何调试安全异常以及如何排除 Maven deps)位于问题 签名者信息不匹配。
A. If you use Maven, a useful way to debug clashing jars is:
For example, for an exception:
we do:
Its output:
shows clashing servlet-api 2.5 and javax.servlet 3.0.0.x.
B. Other useful hints (how to debug the security exception and how to exclude Maven deps) are at the question Signer information does not match.
就我而言,我在库路径中复制了 BouncyCastle 的 JAR 版本:S
In my case, I had duplicated JAR version of BouncyCastle in my library path :S
我有一个类似的例外:
根本问题是我两次包含了 Hamcrest 库。一次使用Maven pom文件。我还将 JUnit 4 库(其中还包含 Hamcrest 库)添加到项目的构建路径中。我只需从构建路径中删除 JUnit,一切都很好。
I had a similar exception:
The root problem was that I included the Hamcrest library twice. Once using Maven pom file. And I also added the JUnit 4 library (which also contains a Hamcrest library) to the project's build path. I simply had to remove JUnit from the build path and everything was fine.
使用 cglib 检测的代理可能会发生这种情况,因为 CGLIB 使用自己的签名者信息而不是应用程序目标类的签名者信息。
This can occur with the cglib-instrumented proxies because CGLIB uses his own signer information instead of the signer information of the application target class.
名称:net/sf/ jasperreports/engine/util/xml/JaxenXPathExecuterFactory.c
姑娘
SHA-256-Digest: q3B5wW+hLX/+lP2+L0/6wRVXRHq1mISBo1dkixT6Vxc=
Name: net/sf/jasperreports/engine/util/xml/JaxenXPathExecuterFactory.c
lass
SHA-256-Digest: q3B5wW+hLX/+lP2+L0/6wRVXRHq1mISBo1dkixT6Vxc=
我在使用 Eclipse 和 JUnit 5 时遇到了这个问题。
我的解决方案受到用户2066936之前的回答的启发
是重新配置导入库的顺序:
I am having this problem with Eclipse and JUnit 5.
My solution is inspired by the previous answer by user2066936
It is to reconfig the ordering of the import libraries:
有点旧的线程,但由于我在这方面停留了相当长的时间,这里是修复(希望它对某人有帮助)。
我的场景:
包名称是:com.abc.def。有 2 个 jar 文件包含此包中的类,例如 jar1 和 jar2,即某些类存在于 jar1 中,其他类存在于 jar2 中。这些 jar 文件使用相同的密钥库进行签名,但在构建过程中的不同时间进行签名(即分别进行签名)。这似乎会导致 jar1 和 jar2 中的文件签名不同。
我将所有文件放入 jar1 中并将它们全部构建(并签名)在一起。问题就消失了。
PS:包名和jar文件名仅是示例
A bit of an old thread but since I was stuck for quite some time on this, here's the fix (hope it helps someone).
My scenario:
The package name is: com.abc.def. There are 2 jar files which contain classes from this package, say jar1 and jar2 i.e. some classes are present in jar1 and others in jar2. These jar files are signed using the same keystore but at different times in the build (i.e. separately). That seems to result in different signatures for the files in jar1 and jar2.
I put all the files in jar1 and built (and signed) them all together. The problem goes away.
PS: The package names and jar file names are only examples
如果您在 Eclipse 中运行它,请检查添加到构建路径的任何项目的 jar;或者执行 control-shift-T 并扫描匹配相同命名空间的多个 jar。然后从项目的构建路径中删除多余或过时的 jar。
If you're running it in Eclipse, check the jars of any projects added to the build path; or do control-shift-T and scan for multiple jars matching the same namespace. Then remove redundant or outdated jars from the project's build path.
就我而言,这是包名称冲突。当前项目和签名引用库在公共
package.foo.utils
中有一个包。只是将当前项目容易出错的包名改成其他的。In my case it was a package name conflict. Current project and signed referenced library had one package in common
package.foo.utils
. Just changed the current project error-prone package name to something else.如果您添加了来自 bouncycastle.org 的所有 jar(在我的例子中来自 crypto-159.zip),只需删除不适用于您的 JDK 的 jar。有裁员。您可能只需要“jdk15on”罐子。
If you added all the jars from bouncycastle.org (in my case from crypto-159.zip), just remove the ones for the JDKs that do not apply to you. There are redundancies. You probably only need the "jdk15on" jars.
这个问题已经持续了很长时间,但我想谈谈一些事情。我一直在从事 Spring 项目挑战,并在 Eclipse IDE 中发现了这一点。如果您将 Maven 或 Gradle 用于 Spring Boot Rest API,则必须删除构建路径中的 Junit 4 或 5,并将 Junit 包含在 pom.xml 或 Gradle 构建文件中。我想这也适用于 yml 配置文件。
This question has lasted for a long time but I want to pitch in something. I have been working on a Spring project challenge and I discovered that in Eclipse IDE. If you are using Maven or Gradle for Spring Boot Rest APIs, you have to remove the Junit 4 or 5 in the build path and include Junit in your pom.xml or Gradle build file. I guess that applies to yml configuration file too.
如果您两次包含一个具有不同名称或来自不同位置的文件,尤其是同一文件的两个不同版本,也会发生这种情况。
This also happens if you include one file with different names or from different locations twice, especially if these are two different versions of the same file.
我可以修好它。
根本原因:
这是使用带有签名 jar 的 Sun JAXB 实现时的常见问题。
本质上,JAXB 实现试图通过生成一个类来直接访问属性而不使用反射来避免反射。不幸的是,它在与正在访问的类相同的包中生成这个新类,这就是此错误的来源。
解决:
添加以下系统属性以禁用与签名 jar 不兼容的 JAXB 优化:
-Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true
参考:https:// /access.redhat.com/site/solutions/42149
I could fix it.
Root Cause:
This is a common issue when using the Sun JAXB implementation with signed jars.
Essentially the JAXB implementation is trying to avoid reflection by generating a class to directly access the properties without using reflection. Unfortunately, it generates this new class in the same package as the class being accessed which is where this error comes from.
Resolution:
Add the following system property to disable the JAXB optimizations that are not compatible with signed jars:
-Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true
Ref: https://access.redhat.com/site/solutions/42149
我在尝试使用 Mockito 时遇到了类似的错误:
我使用的是旧版本的 Mockito,升级到最新的 Mockito 版本解决了这个问题。正如其他答案之一中提到的,问题出在 CGLIB 上。在较新的版本中,Mockito 用 ByteBuddy 替换了 CGLIB,因此问题就消失了。我还必须将新的 ByteBuddy jar 添加到 Eclipse 中的类路径中,以使 Mockito 再次工作。
I was getting a similar error when trying to use Mockito:
I was using an old version of Mockito, and upgrading to the latest Mockito version solved this problem. The issue was with CGLIB as mentioned in one of the other answers. In newer versions, Mockito replaces CGLIB with ByteBuddy, and so the problem goes away. I also had to add the new ByteBuddy jars to the classpath in Eclipse to get Mockito working again.
我正在运行 JUNIT 5 并且还引用了 Hamcrest 外部 jar,但 Hamcrest 也是 JUNIT 5 库的一部分。因此,我将外部 Hamcrest jar 文件的顺序移至构建路径中 JUNIT 5 库的上方。
I was running JUNIT 5 and was also referencing Hamcrest external jar, but Hamcrest is also a part of the JUNIT 5 library. So, I moved the order of the external Hamcrest jar file to be above the JUNIT 5 library in the build path.
我在使用 JUnit + REST Assured + Hamcrest 时发生了这种情况。在这种情况下,请勿将 JUnit 添加到构建路径中。如果您有 Maven 项目,下面的 pom.xml 文件为我解决了这个问题:
This happened to me when using JUnit + REST Assured + Hamcrest. In this case, don't add JUnit to your build path. If you have a Maven project, the below pom.xml file resolved this for me:
我在使用 Intellij 处理多个项目工作区时遇到了麻烦。
结构
项目A
proj B,依赖于 A (在 pom 中使用 Maven 依赖项,因为我们发布了两者)
问题是 B 从 Maven 获取 A,因此它具有不同的签名。
解决办法是编辑IDE项目结构(ctrl+alt+shift+s)->选择项目B->依赖项选项卡->删除maven依赖,点击“+”->模块依赖->选择A。
I had this trouble working on a multiple projects workspace with Intellij.
Structure
proj A
proj B, depend on A (using maven dependency in the pom- as we publish both)
The problem is that B takes A from Maven and therefore it has a different signature.
The solution was to edit the IDE project structure (ctrl+alt+shift+s) -> select proj B -> dependencies tab-> remove the maven dependency, click "+" -> Module dependency -> select A.