Java SecurityException: les informations du signataire ne correspondent pas

J'ai recompilé mes classes comme d'habitude et j'ai soudainement reçu le message d'erreur suivant. Pourquoi? Comment puis-je y remédier?

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)

Cela se produit lorsque des classes appartenant au même package sont chargées à partir de différents fichiers JAR et que ces fichiers JAR ont des signatures signées avec différents certificats - ou, peut-être plus souvent, au moins un est signé et un ou plusieurs autres ne le sont pas (ce qui inclut les classes chargées des répertoires car ces AFAIK ne peuvent pas être signés).

Assurez-vous donc que tous les JAR (ou au moins ceux qui contiennent des classes des mêmes packages) sont signés à l'aide du même certificat, ou supprimez les signatures du manifeste des fichiers JAR avec des packages qui se chevauchent.

Un moyen simple de contourner ce problème est simplement d'essayer de changer l'ordre de vos fichiers jar importés, ce qui peut être fait depuis (Eclipse). Faites un clic droit sur votre package -> Chemin de construction -> Configurer le chemin de construction -> Références et bibliothèques -> Trier et exporter. Essayez de changer l'ordre des fichiers JAR contenant les fichiers de signature.

A. Si vous utilisez maven, un moyen utile de déboguer les fichiers jars en conflit est:

mvn dependency:tree

Par exemple, pour une exception:

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

Nous faisons:

mvn dependency:tree|grep servlet

Sa sortie:

[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

montre des conflits entre servlet-api 2.5 et javax.servlet 3.0.0.x.

B. D'autres conseils utiles (comment déboguer l'exception de sécurité et comment exclure maven deps) se trouvent à la question à l' information du signataire ne correspond pas .

Dans mon cas, j'avais dupliqué la version JAR de BouncyCastle dans le chemin de ma bibliothèque: S

J'ai eu une exception similaire:

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

Le problème principal était que j'ai inclus la bibliothèque Hamcrest deux fois. Une fois en utilisant le fichier pom Maven. Et j'ai également ajouté la bibliothèque JUnit 4 (qui contient également une bibliothèque Hamcrest) au chemin de construction du projet. J'ai simplement dû supprimer JUnit du chemin de construction et tout allait bien.

Cela peut se produire avec les proxys instrumentés par cglib car CGLIB utilise ses propres informations de signataire au lieu des informations de signataire de la classe cible de l'application.

1. Après le signe, accédez à: dist \ lib
2. Trouver des fichiers .jar supplémentaires
3. En utilisant Winrar, vous extrayez pour un dossier (extraire vers "nom du dossier") option
4. Accès: META-INF / MANIFEST.MF
5. Supprimez chaque signature comme ça:

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

1. Enregistrez le fichier
2. Zip à nouveau
3. Renaime ext à .jar retour
4. Déjà

Si vous l'exécutez dans Eclipse, vérifiez les fichiers JAR de tous les projets ajoutés au chemin de construction; ou effectuez control-shift-T et recherchez plusieurs fichiers JAR correspondant au même espace de noms. Supprimez ensuite les fichiers JAR redondants ou obsolètes du chemin de génération du projet.

J'ai ce problème avec Eclipse et JUnit 5. Ma solution est inspirée de la réponse précédente de user2066936 Il s'agit de reconfigurer l'ordre des bibliothèques d'import:

1. Cliquez avec le bouton droit sur le projet.
2. Ouvrez [Java Build Path].
3. Cliquez sur Commander et exporter.
4. Puis poussez JUNIT sur la priorité supérieure.

Dans mon cas, c'était un conflit de nom de package. Le projet actuel et la bibliothèque référencée signée avaient un package en commun package.foo.utils. Je viens de changer le nom du package sujet aux erreurs du projet actuel par autre chose.

Un fil un peu trop ancien mais comme je suis resté coincé pendant un certain temps à ce sujet, voici le correctif (j'espère que cela aide quelqu'un)

Mon scénario:

Le nom du package est: com.abc.def. Il y a 2 fichiers jar qui contiennent des classes de ce paquet, disons jar1 et jar2, c'est-à-dire que certaines classes sont présentes dans jar1 et d'autres dans jar2. Ces fichiers jar sont signés en utilisant le même keystore mais à des moments différents dans la construction (c'est-à-dire séparément). Cela semble entraîner une signature différente pour les fichiers dans jar1 et jar2.

J'ai mis tous les fichiers dans jar1 et les ai tous construits (et signés) ensemble. Le problème disparaît.

PS: les noms de packages et les noms de fichiers jar ne sont que des exemples

Si vous avez ajouté tous les fichiers JAR de bouncycastle.org (dans mon cas de crypto-159.zip), supprimez simplement ceux des JDK qui ne s'appliquent pas à vous. Il y a des licenciements. Vous n'avez probablement besoin que des jars "jdk15on".

Cette question dure depuis longtemps mais je veux apporter quelque chose. J'ai travaillé sur un défi de projet Spring et j'ai découvert cela dans Eclipse IDE. Si vous utilisez Maven ou Gradle pour les API Spring Boot Rest, vous devez supprimer Junit 4 ou 5 dans le chemin de construction et inclure Junit dans votre fichier de construction pom.xml ou Gradle. Je suppose que cela s'applique également au fichier de configuration yml.

Cela se produit également si vous incluez deux fois un fichier avec des noms différents ou des emplacements différents, surtout s'il s'agit de deux versions différentes du même fichier.

Je pourrais le réparer.

Cause fondamentale: il s'agit d'un problème courant lors de l'utilisation de l'implémentation Sun JAXB avec des fichiers JAR signés. Essentiellement, l'implémentation JAXB essaie d'éviter la réflexion en générant une classe pour accéder directement aux propriétés sans utiliser la réflexion. Malheureusement, il génère cette nouvelle classe dans le même package que la classe en cours d'accès, d'où provient cette erreur.

Résolution: ajoutez la propriété système suivante pour désactiver les optimisations JAXB qui ne sont pas compatibles avec les fichiers JAR signés: -Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize = true

Réf: https://access.redhat.com/site/solutions/42149

Sur la base de la réponse @Mohit Phougat, si vous exécutez un Groovy avec des annotations @Grab, vous pouvez essayer de réorganiser ces annotations.

cela m'est arrivé lors de l'utilisation de JUnit + soyez assuré + hamcrest, dans ce cas, n'ajoutez pas junit au chemin de construction, si vous avez le projet maven, cela m'a résolu, ci-dessous le 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>

J'utilisais JUNIT 5 et je faisais également référence au pot externe Hamcrest. Mais Hamcrest fait également partie de la bibliothèque JUNIT 5 . Donc, je dois changer l'ordre du fichier jar Hamecrest externe dans la bibliothèque JUNIT 5 dans le chemin de construction.