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). Клацніть правою кнопкою миші на вашому пакеті -> Шлях збірки -> Налаштування шляху збірки -> Довідник та бібліотеки -> Замовлення та експорт. Спробуйте змінити порядок банок, які містять файли підписів.

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

показує зіткнення servlet-api 2.5 та javax.servlet 3.0.0.x.

B. Інші корисні підказки (як налагодити виняток із безпеки та як виключити deven deps) на запитання щодо інформації Signer не відповідають .

У моєму випадку я копіював 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. І я також додав бібліотеку JUnit 4 (яка також містить бібліотеку Hamcrest) до шляху збирання проекту. Мені просто довелося видалити JUnit зі шляху збірки, і все було добре.

Це може статися з проксі-серверами, що підтримують інструменти, оскільки 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 to .jar назад
4. Вже

Якщо ви запускаєте його в Eclipse, перевірте банки будь-яких проектів, доданих до шляху збирання; або виконайте контроль shift-T і скануйте на кілька банок, що відповідають одному і тому ж простору імен. Потім видаліть зайві або застарілі банки зі шляху складання проекту.

У мене виникають проблеми з Eclipse та JUnit 5. Моє рішення надихає попередня відповідь користувача2066936 Це перенастроювати впорядкування бібліотек імпорту:

1. Клацніть правою кнопкою миші проект.
2. Відкрийте [Шлях збірки Java].
3. Клацніть Замовити та експортувати.
4. Потім натисніть JUNIT до верхнього пріоритету.

У моєму випадку це був конфлікт імені пакета. Поточний проект та підписана бібліотека, що має підписання, мав один пакет package.foo.utils. Щойно змінив назву пакета, схильного до помилок проекту, на щось інше.

Трохи занадто стара тема, але оскільки я досить довго застряг у цьому, ось виправлення (сподіваюся, що це комусь допоможе)

Мій сценарій:

Назва пакету: com.abc.def. Є два файли jar, які містять класи цього пакету, наприклад jar1 та jar2, тобто деякі класи jar1, а інші jar2. Ці файли jar підписуються за допомогою одного і того ж магазину ключів, але в різний час у збірці (тобто окремо). Це, мабуть, призводить до різного підпису для файлів jar1 та jar2.

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

PS: Назви пакетів та імена файлів jar - лише приклади

Якщо ви додали всі банки з bouncycastle.org (у моєму випадку з crypto-159.zip), просто видаліть ті, що стосуються JDK, які не стосуються вас. Є надмірності. Напевно вам потрібні лише банки "jdk15on".

Це питання триває давно, але я хочу щось роздумати. Я працюю над завданням проекту Spring, і я виявив це в IDE Eclipse. Якщо ви використовуєте Maven або Gradle для Spring Boot Rest Rest API, вам потрібно видалити Junit 4 або 5 на шляху збирання та включити Junit у свій файл пам’яті pom.xml або Gradle. Я думаю, що це стосується і файлу конфігурації yml.

Це також відбувається, якщо ви два рази включаєте один файл з різними іменами або з різних місць, особливо якщо це дві різні версії одного файлу.

Я міг би це виправити.

Основна причина: Це поширена проблема при використанні реалізації Sun JAXB з підписаними банками. По суті, реалізація JAXB намагається уникнути рефлексії шляхом створення класу для прямого доступу до властивостей без використання відображення. На жаль, він генерує цей новий клас у тому ж пакеті, що і клас, до якого звертаються, звідки походить ця помилка.

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

Довідка: https://access.redhat.com/site/solutions/42149

На основі @Mohit Phougat відповіді, якщо ви використовуєте Groovy з анотаціями @Grab, ви можете спробувати змінити такі примітки.

це сталося зі мною при використанні JUnit + будьте впевнені + 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 під час складання.