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

A. Если вы используете Maven, полезный способ отладки конфликтующих фляг:

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.

B. Другие полезные советы (как отладить исключение безопасности и как исключить 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 девушка SHA-256-дайджест: q3B5wW + hLX / + lP2 + L0 / 6wRVXRHq1mISBo1dkixT6Vxc =

1. Сохранить файл
2. Застегните молнию снова
3. Renaime ext to .jar back
4. Уже

Answer 8

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

Answer 9

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

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

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

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

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

Answer 10

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