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)

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

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

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

A. Если вы используете 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. Другие полезные советы (как отладить исключение безопасности и как исключить maven deps) находятся на вопросе у подписывающей стороны, информация не совпадает .

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

У меня было аналогичное исключение:

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 file. И я также добавил библиотеку JUnit 4 (которая также содержит библиотеку Hamcrest) в путь сборки проекта. Мне просто пришлось удалить JUnit из пути сборки, и все было в порядке.

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

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. Renaime ext в .jar назад
4. Уже

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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