Java SecurityException: informacje podpisującego nie są zgodne

Ponownie skompilowałem swoje klasy jak zwykle i nagle otrzymałem następujący komunikat o błędzie. Czemu? Jak mogę to naprawić?

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)

Dzieje się tak, gdy klasy należące do tego samego pakietu są ładowane z różnych plików JAR, a te pliki JAR mają podpisy podpisane różnymi certyfikatami - lub, być może częściej, przynajmniej jeden jest podpisany, a co najmniej jeden nie (co obejmuje załadowane klasy z katalogów, ponieważ te AFAIK nie mogą być podpisane).

Więc albo upewnij się, że wszystkie pliki JAR (lub przynajmniej te, które zawierają klasy z tych samych pakietów) są podpisane tym samym certyfikatem, albo usuń podpisy z manifestu plików JAR z nakładającymi się pakietami.

Prostym sposobem obejścia tego problemu jest zmiana kolejności importowanych plików jar, co można zrobić z (Eclipse). Kliknij prawym przyciskiem myszy pakiet -> Ścieżka kompilacji -> Konfiguruj ścieżkę kompilacji -> Referencje i biblioteki -> Zamów i eksportuj. Spróbuj zmienić kolejność słoików, które zawierają pliki sygnatur.

O. Jeśli używasz mavena, przydatnym sposobem debugowania kolizji słoików jest:

mvn dependency:tree

Na przykład dla wyjątku:

java.lang.SecurityException: class "javax.servlet.HttpConstraintElement"'s signer information does not match signer information of other classes in the same package

my robimy:

mvn dependency:tree|grep servlet

Jego wydajność:

[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

pokazuje kolizję servlet-api 2.5 i javax.servlet 3.0.0.x.

B. Inne przydatne wskazówki (jak debugować wyjątek bezpieczeństwa i jak wykluczyć deps maven) znajdują się w pytaniu o niezgodności informacji podpisującego .

W moim przypadku zduplikowałem wersję JAR BouncyCastle w mojej ścieżce do biblioteki: S

Miałem podobny wyjątek:

java.lang.SecurityException: class "org.hamcrest.Matchers"'s signer information does not match signer information of other classes in the same package

Główny problem polegał na tym, że dwukrotnie włączyłem bibliotekę Hamcrest. Po użyciu pliku pom Maven. Dodałem także bibliotekę JUnit 4 (która zawiera również bibliotekę Hamcrest) do ścieżki budowania projektu. Po prostu musiałem usunąć JUnit ze ścieżki kompilacji i wszystko było w porządku.

Taka sytuacja może wystąpić w przypadku serwerów proxy z instrumentami cglib, ponieważ CGLIB używa własnych informacji o sygnatariuszu zamiast informacji o sygnatariuszu klasy docelowej aplikacji.

1. Po podpisaniu dostęp: dist \ lib
2. Znajdź dodatkowy plik .jar
3. Używając Winrar, możesz wypakować dla folderu (wypakować do „nazwa folderu”)
4. Dostęp: META-INF / MANIFEST.MF
5. Usuń każdy podpis w ten sposób:

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

1. Zapisz plik
2. Zip ponownie
3. Renaime ext do .jar z powrotem
4. Już

Jeśli uruchamiasz go w Eclipse, sprawdź pliki JAR wszystkich projektów dodanych do ścieżki kompilacji; lub wykonaj Ctrl-Shift-T i wyszukaj wiele plików jar pasujących do tej samej przestrzeni nazw. Następnie usuń zbędne lub nieaktualne pliki JAR ze ścieżki kompilacji projektu.

Mam ten problem z Eclipse i JUnit 5. Moje rozwiązanie jest inspirowane poprzednią odpowiedzią użytkownika2066936. Chodzi o zmianę kolejności bibliotek importu:

1. Kliknij projekt prawym przyciskiem myszy.
2. Otwórz [Ścieżkę budowania Java].
3. Kliknij Zamów i eksportuj.
4. Następnie przesuń JUNIT do wyższego priorytetu.

W moim przypadku był to konflikt nazw pakietów. Bieżący projekt i podpisana biblioteka, do której się odwołuje, miały jeden wspólny pakiet package.foo.utils. Właśnie zmieniłem nazwę pakietu podatnego na błędy projektu na inną.

Trochę za stary wątek, ale ponieważ utknąłem w tym przez dłuższy czas, oto poprawka (mam nadzieję, że to komuś pomoże)

Mój scenariusz:

Nazwa pakietu to: com.abc.def. Istnieją 2 pliki jar, które zawierają klasy z tego pakietu, np. Jar1 i jar2, tj. Niektóre klasy znajdują się w jar1, a inne w jar2. Te pliki jar są podpisywane przy użyciu tego samego magazynu kluczy, ale w różnych momentach kompilacji (tj. Oddzielnie). Wydaje się, że skutkuje to różnymi sygnaturami dla plików w jar1 i jar2.

Umieściłem wszystkie pliki w jar1 i zbudowałem (i podpisałem) je wszystkie razem. Problem znika.

PS: Nazwy pakietów i nazwy plików jar są tylko przykładami

Jeśli dodałeś wszystkie słoiki z bouncycastle.org (w moim przypadku z crypto-159.zip), po prostu usuń te dla JDK, które Cię nie dotyczą. Istnieją zwolnienia. Prawdopodobnie potrzebujesz tylko słoików „jdk15on”.

To pytanie trwało długo, ale chcę w coś odpowiedzieć. Pracowałem nad wyzwaniem projektu Spring i odkryłem to w Eclipse IDE. Jeśli używasz Maven lub Gradle do Spring Boot Rest API, musisz usunąć Junit 4 lub 5 ze ścieżki kompilacji i dołączyć Junit do pliku kompilacji pom.xml lub Gradle. Myślę, że dotyczy to również pliku konfiguracyjnego yml.

Dzieje się tak również wtedy, gdy dwa razy dołączysz jeden plik o różnych nazwach lub z różnych lokalizacji, zwłaszcza jeśli są to dwie różne wersje tego samego pliku.

Mógłbym to naprawić.

Główna przyczyna: Jest to częsty problem podczas używania implementacji Sun JAXB z podpisanymi plikami JAR. Zasadniczo implementacja JAXB próbuje uniknąć odbicia, generując klasę, aby uzyskać bezpośredni dostęp do właściwości bez używania odbicia. Niestety, generuje tę nową klasę w tym samym pakiecie, co klasa, do której uzyskiwany jest dostęp, skąd pochodzi ten błąd.

Rozwiązanie: Dodaj następującą właściwość systemową, aby wyłączyć optymalizacje JAXB, które nie są zgodne z podpisanymi plikami JAR: -Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize = true

Ref: https://access.redhat.com/site/solutions/42149

Opierając się na odpowiedzi @Mohit Phougat, jeśli używasz Groovy z adnotacjami @Grab, możesz spróbować ponownie zamówić takie adnotacje.

zdarzyło mi się to podczas używania JUnit + spokojnie + hamcrest, w tym przypadku nie dodawaj junita do ścieżki budowania, jeśli masz projekt maven, to rozwiązało mnie, poniżej jest 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>

Biegałam JUnit 5 a także przedstawieniu Hamcrest zewnętrznego jar. Ale Hamcrest jest również częścią biblioteki JUNIT 5 . Więc muszę zmienić kolejność zewnętrznego pliku jar Hamecrest w bibliotece JUNIT 5 w ścieżce kompilacji.