Java SecurityException: информация подписавшего не совпадает

Question

Я перекомпилировал свои классы как обычно, и внезапно получил следующее сообщение об ошибке. Зачем? Как я могу это исправить?

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)

Answer 1

Это происходит, когда классы, принадлежащие одному и тому же пакету, загружаются из разных файлов JAR, и эти файлы JAR имеют подписи, подписанные разными сертификатами - или, возможно, чаще, по крайней мере, один подписан, а один или несколько других нет (который включает загруженные классы). из каталогов, так как эти AFAIK не могут быть подписаны).

Поэтому убедитесь, что все JAR-файлы (или, по крайней мере, те, которые содержат классы из одинаковых пакетов) подписаны с использованием одного и того же сертификата, или удалите подписи из манифеста файлов JAR с перекрывающимися пакетами.

Answer 2

Простой способ обойти это - просто попытаться изменить порядок импортированных файлов JAR, что можно сделать из (Eclipse). Щелкните правой кнопкой мыши по вашему пакету -> Путь сборки -> Настроить путь сборки -> Ссылки и библиотеки -> Порядок и экспорт. Попробуйте изменить порядок банок, которые содержат файлы подписи.

Answer 3

О. Если вы используете 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

показывает конфликтующие сервлет-api 2.5 и javax.servlet 3.0.0.x.

Б. Другие полезные советы (как отладить исключение безопасности и как исключить maven deps) в вопросе у подписавшего информация не совпадает.

Answer 4

В моем случае я дублировал JAR-версию BouncyCastle в моем пути к библиотеке:S

Answer 5

У меня было похожее исключение:

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 из пути сборки, и все было хорошо.

Answer 6

Это может происходить с прокси-инструментами cglib, потому что CGLIB использует свою собственную информацию подписавшего вместо информации подписывающего целевого класса приложения.

Answer 7

1. После знака, доступ: dist\lib
2. Найти дополнительный.jar
3. Используя Winrar, вы извлекаете для папки (извлечение в "имя папки") вариант
4. Доступ: META-INF/MANIFEST.MF
5. Удалить каждую подпись так:

Имя: net/sf/jasperreports/engine/util/xml/JaxenXPathExecuterFactory.c lass SHA-256-Digest: q3B5wW+hLX/+lP2+L0/6wRVXRHq1mISBo1dkixT6Vxc=

1. Сохранить файл
2. Застегните молнию снова
3. Ренайм доб. Назад
4. Уже

Answer 8

Слишком старая тема, но так как я застрял на этом некоторое время, вот исправление (надеюсь, это кому-нибудь поможет)

Мой сценарий:

Имя пакета: com.abc.def. Есть 2 файла jar, которые содержат классы из этого пакета, например, jar1 и jar2, т.е. некоторые классы присутствуют в jar1, а другие - в jar2. Эти файлы JAR подписаны с использованием одного и того же хранилища ключей, но в разное время сборки (т. Е. Отдельно). Это, кажется, приводит к другой подписи для файлов в jar1 и jar2.

Я поместил все файлы в jar1 и собрал (и подписал) их все вместе. Проблема уходит.

PS: имена пакетов и имена файлов JAR являются только примерами

Answer 9

У меня проблема с Eclipse и JUnit 5. Мое решение основано на предыдущем ответе user2066936. Это изменение порядка библиотек импорта:

1. Щелкните проект правой кнопкой мыши.
2. Откройте [Путь сборки Java].
3. Щелкните "Заказ и экспорт".
4. Затем установите JUNIT на более высокий приоритет.

Answer 10

Если вы запускаете его в Eclipse, проверьте файлы jar всех проектов, добавленных в путь сборки; или сделайте control-shift-T и сканируйте несколько jar-файлов, соответствующих одному и тому же пространству имен. Затем удалите избыточные или устаревшие файлы JAR из пути сборки проекта.

Answer 11

В моем случае это был конфликт имени пакета. Текущий проект и подписанная ссылочная библиотека имели один общий пакет package.foo.utils, Просто изменил имя текущего подверженного ошибкам пакета пакета на что-то другое.

Answer 12

Если вы добавили все jar-файлы с bouncycastle.org (в моем случае с crypto-159.zip), просто удалите те файлы JDK, которые к вам не относятся. Есть увольнения. Вам, вероятно, нужны только банки jdk15on.

Answer 13

Этот вопрос длился давно, но я хочу кое-что сказать. Я работал над проблемой проекта Spring и обнаружил это в Eclipse IDE. Если вы используете Maven или Gradle для API Spring Boot Rest, вам необходимо удалить Junit 4 или 5 в пути сборки и включить Junit в свой файл сборки pom.xml или Gradle. Думаю, это относится и к конфигурационному файлу yml.

Answer 14

Я мог бы это исправить.

Основная причина: это распространенная проблема при использовании реализации Sun JAXB с подписанными банками. По сути, реализация JAXB пытается избежать отражения, генерируя класс для прямого доступа к свойствам без использования отражения. К сожалению, он генерирует этот новый класс в том же пакете, что и класс, к которому осуществляется доступ, откуда и происходит эта ошибка.

Решение. Добавьте следующее системное свойство, чтобы отключить оптимизации JAXB, несовместимые с подписанными файлами jar: -Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true

Ссылка: https://access.redhat.com/site/solutions/42149

Answer 15

Это также происходит, если вы включаете один файл с разными именами или из разных мест дважды, особенно если это две разные версии одного и того же файла.

Answer 16

Исходя из ответа @Mohit Phougat, если вы используете Groovy с аннотациями @Grab, вы можете попытаться изменить порядок таких аннотаций.

Answer 17

Я запускал JUNIT 5 и также ссылался на внешнюю банку Hamcrest. Но Hamcrest также является частью библиотеки JUNIT 5. Итак, мне нужно изменить порядок внешнего файла jar Hamecrest в библиотеке JUNIT 5 в пути сборки.

Answer 18

Это случилось со мной при использовании JUnit + rest assured + 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>

Answer 19

Я получал аналогичную ошибку при попытке использовать Mockito:

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

Я использовал старую версию Mockito, и обновление до последней версии Mockito решило эту проблему. Проблема заключалась в CGLIB, как упоминалось в одном из других ответов. В более новых версиях Mockito заменяет CGLIB на ByteBuddy, и проблема решается. Мне также пришлось добавить новые банки ByteBuddy в путь к классам в Eclipse, чтобы Mockito снова заработал.