«Fichier de signature non valide» lors de la tentative d'exécution d'un .jar

Mon programme java est empaqueté dans un fichier jar et utilise une bibliothèque jar externe, château gonflable . Mon code se compile bien, mais l'exécution du bocal conduit à l'erreur suivante:

Exception dans le thread "principal" java.lang.SecurityException: résumé de fichier de signature non valide pour les attributs principaux du manifeste

J'ai googlé pendant plus d'une heure à la recherche d'une explication et trouvé très peu de valeur. Si quelqu'un a déjà vu cette erreur et pourrait offrir de l'aide, je serais obligé.

La solution répertoriée ici peut fournir un pointeur.

Résumé de fichier de signature non valide pour les attributs principaux du manifeste

Conclusion:

Il est probablement préférable de conserver le fichier jar officiel tel quel et de l'ajouter simplement en tant que dépendance dans le fichier manifeste de votre fichier jar d'application.

Pour ceux qui ont obtenu cette erreur en essayant de créer un uber-jar avec maven-shade-plugin, la solution consiste à exclure les fichiers de signature manifeste en ajoutant les lignes suivantes à la configuration du plugin:

<configuration>
    <filters>
        <filter>
            <artifact>*:*</artifact>
            <excludes>
                <exclude>META-INF/*.SF</exclude>
                <exclude>META-INF/*.DSA</exclude>
                <exclude>META-INF/*.RSA</exclude>
            </excludes>
        </filter>
    </filters>
    <!-- Additional configuration. -->
</configuration>

Pour ceux qui utilisent gradle et essaient de créer et d'utiliser un gros pot, la syntaxe suivante pourrait aider.

jar {
    doFirst {
        from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } } 
    }
    exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA' 
}

Certaines de vos dépendances sont probablement des fichiers jar signés. Lorsque vous les combinez tous en un seul grand fichier jar, les fichiers de signature correspondants sont toujours présents et ne correspondent plus au fichier jar "grand combiné", de sorte que l'exécution s'arrête en pensant que le fichier jar a été falsifié (ce qu'il ... a donc pour parler).

Vous pouvez résoudre le problème en éliminant les fichiers de signature de vos dépendances jarfile. Malheureusement, il n'est pas possible de le faire en une seule étape .

Cependant, j'ai pu faire fonctionner cela avec Ant en deux étapes, sans nommer spécifiquement chaque dépendance de fichier jar, en utilisant:

<target name="jar" depends="compile" description="Create one big jarfile.">
    <jar jarfile="${output.dir}/deps.jar">
        <zipgroupfileset dir="jars">
            <include name="**/*.jar" />
        </zipgroupfileset>
    </jar>
    <sleep seconds="1" />
    <jar jarfile="${output.dir}/myjar.jar" basedir="${classes.dir}">
        <zipfileset src="${output.dir}/deps.jar" excludes="META-INF/*.SF" />
        <manifest>
            <attribute name="Main-Class" value="com.mycompany.MyMain" />
        </manifest>
    </jar>
</target>

L'élément sleep est censé empêcher les erreurs sur les fichiers avec des dates de modification à l'avenir .

D'autres variantes que j'ai trouvées dans les fils liés ne fonctionnaient pas pour moi.

Veuillez utiliser la commande suivante

zip -d yourjar.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*SF'

J'ai rencontré ce problème lors de l'utilisation d'IntelliJ IDEA 14.01.

J'ai pu le réparer en:

Fichier-> Structure du projet-> Ajouter un nouveau (artefacts) -> jar-> À partir des modules avec des dépendances dans la fenêtre Créer un pot à partir du module:

Sélectionnez votre classe principale

Fichier JAR des bibliothèques Sélectionnez la copie dans le répertoire de sortie et liez via le manifeste

La sécurité est déjà un sujet difficile, mais je suis déçu de voir que la solution la plus populaire consiste à supprimer les signatures de sécurité. JCE requiert ces signatures . L'ombre Maven explose le fichier de pot BouncyCastle qui place les signatures dans META-INF, mais les signatures BouncyCastle ne sont pas valides pour un nouveau pot uber (uniquement pour le pot BC), et c'est ce qui provoque l'erreur de signature non valide dans ce fil .

Oui, l'exclusion ou la suppression des signatures comme suggéré par @ruhsuzbaykus fait en effet disparaître l'erreur d'origine, mais elle peut également conduire à de nouvelles erreurs cryptiques:

java.security.NoSuchAlgorithmException: PBEWithSHA256And256BitAES-CBC-BC SecretKeyFactory not available

En spécifiant explicitement où trouver l'algorithme comme ceci:

SecretKeyFactory.getInstance("PBEWithSHA256And256BitAES-CBC-BC","BC");

J'ai pu obtenir une erreur différente:

java.security.NoSuchProviderException: JCE cannot authenticate the provider BC

JCE ne peut pas authentifier le fournisseur car nous avons supprimé les signatures cryptographiques en suivant la suggestion ailleurs dans ce même fil .

La solution que j'ai trouvée était le plugin packer exécutable qui utilise une approche jar-in-jar pour préserver la signature BouncyCastle dans un seul pot exécutable.

MISE À JOUR :

Une autre façon de le faire (la bonne façon?) Est d'utiliser le signataire Maven Jar . Cela vous permet de continuer à utiliser l'ombre Maven sans obtenir d'erreurs de sécurité. CEPENDANT, vous devez avoir un certificat de signature de code (Oracle suggère de rechercher "Certificat de signature de code Java"). La configuration POM ressemble à ceci:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>3.1.0</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <filters>
                    <filter>
                        <artifact>org.bouncycastle:*</artifact>
                        <excludes>
                            <exclude>META-INF/*.SF</exclude>
                            <exclude>META-INF/*.DSA</exclude>
                            <exclude>META-INF/*.RSA</exclude>
                        </excludes>
                    </filter>
                </filters>
                <transformers>
                    <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                        <mainClass>your.class.here</mainClass>
                    </transformer>
                </transformers>
                <shadedArtifactAttached>true</shadedArtifactAttached>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jarsigner-plugin</artifactId>
    <version>1.4</version>
    <executions>
        <execution>
            <id>sign</id>
            <goals>
                <goal>sign</goal>
            </goals>
        </execution>
        <execution>
            <id>verify</id>
            <goals>
                <goal>verify</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <keystore>/path/to/myKeystore</keystore>
        <alias>myfirstkey</alias>
        <storepass>111111</storepass>
        <keypass>111111</keypass>
    </configuration>
</plugin>

Non, il n'y a aucun moyen pour que JCE reconnaisse un certificat auto-signé, donc si vous devez conserver les certificats BouncyCastle, vous devez soit utiliser le plugin jar-in-jar, soit obtenir un certificat JCE.

J'ai fait face au même problème, après référence quelque part, cela a fonctionné comme ci-dessous en changeant:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>3.2.1</version>
    <configuration>
        <createDependencyReducedPom>false</createDependencyReducedPom>
    </configuration>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <filters>
                    <filter>
                        <artifact>*:*</artifact>
                        <excludes>
                            <exclude>META-INF/*.SF</exclude>
                            <exclude>META-INF/*.DSA</exclude>
                            <exclude>META-INF/*.RSA</exclude>
                        </excludes>
                    </filter>
                </filters>
            </configuration>
        </execution>
    </executions>
</plugin>

En supposant que vous construisez votre fichier jar avec ant, vous pouvez simplement demander à ant de laisser de côté le répertoire META-INF. Ceci est une version simplifiée de ma cible de fourmi:

<jar destfile="app.jar" basedir="${classes.dir}">
    <zipfileset excludes="META-INF/**/*" src="${lib.dir}/bcprov-jdk16-145.jar"></zipfileset>
    <manifest>
        <attribute name="Main-Class" value="app.Main"/>
    </manifest>
</jar>

J'ai récemment commencé à utiliser IntelliJ sur mes projets. Cependant, certains de mes collègues utilisent toujours Eclipse sur les mêmes projets. Aujourd'hui, j'ai la même erreur après avoir exécuté le fichier jar créé par mon IntelliJ. Alors que toutes les solutions ici parlent de presque la même chose, aucune d'entre elles n'a fonctionné facilement pour moi (peut-être parce que je n'utilise pas ANT, maven build m'a donné d'autres erreurs qui m'ont renvoyé à http://cwiki.apache.org/ confluence / affichage / MAVEN / MojoExecutionException , et je n'ai pas pu comprendre par moi-même quels sont les pots signés!)

Enfin, cela m'a aidé

zip -d demoSampler.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*SF'

Devinez ce qui a été supprimé de mon fichier jar?!

deleting: META-INF/ECLIPSE_.SF 
deleting: META-INF/ECLIPSE_.RSA

Il semble que le problème concernait certains fichiers liés à l'éclipse.

J'ai eu le même problème gradlelors de la création d'un gros bocal, la mise à jour du build.gradlefichier avec une ligne d'exclusion a corrigé le problème.

jar {
    from {
        configurations.compile.collect {
            it.isDirectory() ? it : zipTree(it)
        }
    }
    exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA'
    manifest {
        attributes 'Main-Class': 'com.test.Main'
    }
}

Dans le cas où vous utilisez gradle, voici une tâche farJar complète:

version = '1.0'
//create a single Jar with all dependencies
task fatJar(type: Jar) {
    manifest {
        attributes 'Implementation-Title': 'Gradle Jar File Example',  
            'Implementation-Version': version,
            'Main-Class': 'com.example.main'
    }
    baseName = project.name + '-all'
    from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } }
    exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA' 
    with jar
}

Comparez le dossier META-INF dans le nouveau pot avec l'ancien pot (avant d'ajouter de nouvelles bibliothèques). Il est possible qu'il y ait de nouveaux fichiers. Si oui, vous pouvez les supprimer. Ça devrait aider. Cordialement, 999michal

Une stratégie consisterait à utiliser ANT pour simplifier la suppression de la signature de chaque fichier Jar. Il procéderait avec les étapes suivantes:

1. Copie du MANIFEST.MF dans un fichier temporaire
2. Suppression des entrées Nom et SHA du fichier temporaire
3. Création d'un fichier Jar temporaire avec le manifeste temporaire
4. Suppression du manifeste temporaire
5. Échange du fichier Jar d'origine avec le fichier temporaire

Voici un macrodef ANT qui fait le travail:

<macrodef name="unsignjar" description="To unsign a specific Jar file">
    <attribute name="jarfile" 
        description="The jar file to unsign" />
    <sequential>
<!-- Copying to the temporary manifest file -->
        <copy toFile="@{jarFile}_MANIFEST.tmp">
            <resources>
                <zipentry zipfile="@{jarFile}" name="META-INF/MANIFEST.MF"/>
            </resources>
        </copy>
<!-- Removing the Name and SHA entries from the temporary file -->
        <replaceregexp file="@{jarFile}_MANIFEST.tmp" match="\nName:(.+?)\nSH" replace="SH" flags="gis" byline="false"/>
        <replaceregexp file="@{jarFile}_MANIFEST.tmp" match="SHA(.*)" replace="" flags="gis" byline="false"/>
<!-- Creating a temporary Jar file with the temporary manifest -->
        <jar jarfile="@{jarFile}.tmp"
            manifest="@{jarFile}_MANIFEST.tmp">
            <zipfileset src="@{jarFile}">
                <include name="**"/>
                <exclude name="META-INF/*.SF"/>
                <exclude name="META-INF/*.DSA"/>
                <exclude name="META-INF/*.RSA"/>
            </zipfileset>
        </jar>
<!-- Removing the temporary manifest -->
        <delete file="@{jarFile}_MANIFEST.tmp" />
<!-- Swapping the original Jar file with the temporary one -->
        <move file="@{jarFile}.tmp"
              tofile="@{jarFile}"
              overwrite="true" />
</sequential>

"

La définition peut ensuite être appelée de cette façon dans une tâche ANT:

<target name="unsignJar">
    <unsignjar jarFile="org.test.myjartounsign.jar" />
</target>

Erreur: une erreur JNI s'est produite, veuillez vérifier votre installation et réessayer Exception dans le thread "main" java.lang.SecurityException: résumé de fichier de signature non valide pour les attributs principaux du manifeste à sun.security.util.SignatureFileVerifier.processImpl (SignatureFileVerifier.java: 314) sur sun.security.util.SignatureFileVerifier.process (SignatureFileVerifier.java:268) sur java.util.jar.JarVerifier.processEntry (JarVerifier.java:316) sur java.util.jar.JarVerifier.update (JarVerifier.java : 228) sur java.util.jar.JarFile.initializeVerifier (JarFile.java:383) sur java.util.jar.JarFile.getInputStream (JarFile.java:450) sur sun.misc.URLClassPath $ JarLoader $ 2.getInputStream (URLClassPath .java: 977) à sun.misc.Resource.cachedInputStream (Resource.java:77) à sun.misc.Resource.getByteBuffer (Resource.java:160) sur java.net.URLClassLoader.defineClass (URLClassLoader.java:454) sur java.net.URLClassLoader.access 100 $ (URLClassLoader.java:73) sur java.net.URLClassLoader $ 1.run (URLClassLoader.java:368) sur java.net.URLClassLoader $ 1.run (URLClassLoader.java:362) sur java.security.AccessController.doPrivileged (Native Method) sur java.net.URLClassLoader.findClass (URLClassLoader.java:361) sur java.lang.ClassLoader.loadClass (ClassLoader.java:424) sur sun.misc.Launcher $ AppClassLoader.loadClass (Launcher.java:331) sur java.lang.ClassLoader.loadClass (ClassLoader.java:357) sur sun.launcher.LauncherHelper.checkAndLoadMain (LauncherHelper. java: 495)run (URLClassLoader.java:368) at java.net.URLClassLoader $ 1. run (URLClassLoader.java:362) at java.security.AccessController.doPrivileged (Native Method) at java.net.URLClassLoader.findClass (URLClassLoader.java:361 ) à java.lang.ClassLoader.loadClass (ClassLoader.java:424) à sun.misc.Launcher $ AppClassLoader.loadClass (Launcher.java:331) à java.lang.ClassLoader.loadClass (ClassLoader.java:357) au soleil .launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)run (URLClassLoader.java:368) at java.net.URLClassLoader $ 1. run (URLClassLoader.java:362) at java.security.AccessController.doPrivileged (Native Method) at java.net.URLClassLoader.findClass (URLClassLoader.java:361 ) à java.lang.ClassLoader.loadClass (ClassLoader.java:424) à sun.misc.Launcher $ AppClassLoader.loadClass (Launcher.java:331) à java.lang.ClassLoader.loadClass (ClassLoader.java:357) au soleil .launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)331) sur java.lang.ClassLoader.loadClass (ClassLoader.java:357) sur sun.launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)331) sur java.lang.ClassLoader.loadClass (ClassLoader.java:357) sur sun.launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)

Ce qui m'a aidé (IntelliJ IDEA 2016.3): Fichier -> Structure du projet -> Artefacts -> Ajouter JAR -> Sélectionner la classe principale -> Choisissez "copier dans le répertoire de sortie et lier via le manifeste" -> OK -> Appliquer -> Construire - > Construire des artefacts ... -> Construire

Il est possible que deux signataires différents gâchent l'esprit Java.

Essayez de supprimer le dossier META-INF du pot, en ajoutant à nouveau le manifeste et en signant le JAR, cela m'a aidé: http://jehy.ru/articles/2013/12/13/invalid-signature-file-digest-for-manifest-main- les attributs/

Si vous recherchez une solution Fat JAR sans déballer ni altérer les bibliothèques originales mais avec un chargeur de classe JAR spécial, jetez un œil à mon projet ici .

Avertissement: je n'ai pas écrit le code, il suffit de l'empaqueter et de le publier sur Maven Central et de décrire dans mon fichier Lisez-moi comment l'utiliser.

Je l'utilise personnellement pour créer des fichiers JAR uber exécutables contenant des dépendances BouncyCastle. Peut-être que cela vous est également utile.

Pour ceux qui ont des problèmes avec la solution acceptée, il existe une autre façon d'exclure des ressources du pot ombré avec DontIncludeResourceTransformer:

https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#DontIncludeResourceTransformer

          <transformers>
            <transformer implementation="org.apache.maven.plugins.shade.resource.DontIncludeResourceTransformer">
                <resource>BC1024KE.DSA</resource>
            </transformer>
          </transformers>

Depuis Shade 3.0, ce transformateur accepte une liste de ressources. Avant cela, il vous suffit d'utiliser plusieurs transformateurs chacun avec une seule ressource.

Cela m'est arrivé dans Intellij lorsque j'ai cliqué sur "Ajouter en tant que projet Maven" sur la dernière ligne quand Intellij a dit "fichiers pom non gérés trouvés". Pendant ce temps, le dossier out a déjà été généré. Il n'a donc pas été modifié récemment.

La suppression du dossier et l'exécution du programme ont résolu le problème pour moi. le dossier a ensuite été recréé.

Voir aussi la réponse de Little Fox. L'erreur que j'ai reçue était très similaire à la sienne.

J'avais un problème similaire. La raison en était que je compilais en utilisant un JDK avec un JRE différent de celui par défaut dans ma boîte Windows.

L'utilisation du java.exe correct a résolu mon problème.

Si vous obtenez cela lorsque vous essayez de lier des fichiers JAR pour un projet de liaisons Xamarin.Android comme ceci:

JARTOXML: avertissement J2XA006: une erreur de classe manquante a été déclenchée lors de la réflexion de com.your.class: condensé de fichier de signature non valide pour les attributs principaux du manifeste

Ouvrez simplement les fichiers JAR à l'aide de Winzip et supprimez les répertoires meta-inf. Reconstruire - travail effectué