„Ungültige Signaturdatei“ beim Versuch, eine .jar zu laufen
https://stackoverflow.com/questions/999489
-
14-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Ihr Java-Programm wird in einer JAR-Datei verpackt und macht die Verwendung einer externen jar Bibliothek, Hüpfburg . Mein Code kompiliert in Ordnung, aber läuft das Glas führt zu dem folgenden Fehler:
Exception in thread "main" java.lang.SecurityException: Ungültige Signaturdatei für Manifest Hauptattribute verdaut
Ich habe gegoogelt für mehr als eine Stunde nach einer Erklärung gesucht und gefunden sehr wenig Wert. Wenn jemand diesen Fehler gesehen hat, vor und könnte etwas Hilfe anbieten, würde ich dazu verpflichtet werden.
Lösung
Die Lösung hier aufgeführten könnte einen Zeiger liefern.
Ungültige Signaturdatei für Manifest Hauptattribute verdauen
Fazit:
Es ist wahrscheinlich am besten das offizielle Glas zu halten, wie ist und es nur als eine Abhängigkeit in der Manifest-Datei hinzufügen, für Ihre Anwendung jar-Datei.
Andere Tipps
Für diejenigen, die diesen Fehler bekamen beim Versuch, einen uber-jar mit maven-shade-plugin zu schaffen, ist die Lösung auszuschließen manifest Signaturdateien durch die folgenden Zeilen in der Plugin-Konfiguration hinzufügen:
<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>
Für die gradle verwenden und versuchen, ein Fett Glas zu erstellen und zu verwenden, wird die folgende Syntax helfen könnte.
jar {
doFirst {
from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } }
}
exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA'
}
Einige Ihrer Abhängigkeiten jarfiles wahrscheinlich unterzeichnet. Wenn man sie alle in eine große jarfile kombinieren, sind die entsprechenden Signaturdateien noch vorhanden ist, und nicht mehr entsprechen den „großen kombinierten“ jarfile, so dass die Laufzeit das Glas hält Denken Datei manipuliert wurde (was ... es hat so zu sprechen).
Sie können das Problem lösen, indem Sie die Signaturdateien von Ihren jarfile Abhängigkeiten zu beseitigen. Leider es nicht möglich ist, diese in ant in einem Schritt zu tun.
Allerdings konnte ich diese Arbeit mit Ant in zwei Schritten bekommen, ohne ausdrücklich jede jarfile Abhängigkeit der Benennung durch die Verwendung:
<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>
Der Schlaf Element soll Fehler über Dateien mit Änderungsdaten in Zukunft verhindern.
Weitere Variationen I in den verknüpften Themen gefunden haben für mich nicht.
Bitte benutzen Sie den folgenden Befehl
zip -d yourjar.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*SF'
hatte ich dieses Problem bei der Verwendung von IntelliJ IDEA 14.01.
Ich war in der Lage, es zu beheben, indem Sie:
File-> Projekt Struktur-> New (Artefakte) -> JAR> Von Module mit Abhängigkeiten von dem Erstellen Jar von Modul-Fenstern:
Wählen Sie Hauptklasse
JAR-Datei von Bibliotheken Wählen Sie Kopie in das Ausgabeverzeichnis und Link über Manifest
Die Sicherheit ist schon ein hartes Thema, aber ich bin enttäuscht die beliebteste Lösung zu sehen ist, die Sicherheitssignaturen zu löschen. JCE erfordert diese Signaturen . Maven Schatten explodieren die BouncyCastle JAR-Datei, die die Signaturen in META-INF setzt, aber die BouncyCastle Signaturen sind nicht gültig für einen neuen, uber-jar (nur für das BC Glas) und das ist, was die ungültigen Signatur Fehler verursacht in diesem Thread .
Ja, ohne oder Löschen der Unterschriften, wie durch @ruhsuzbaykus vorgeschlagen hat in der Tat der ursprüngliche Fehler weggehen, aber es kann auch zu neuen, kryptischen Fehler führen:
java.security.NoSuchAlgorithmException: PBEWithSHA256And256BitAES-CBC-BC SecretKeyFactory not available
Durch die explizite Angabe, wo der Algorithmus wie folgt zu finden:
SecretKeyFactory.getInstance("PBEWithSHA256And256BitAES-CBC-BC","BC");
konnte ich einen anderen Fehler erhalten:
java.security.NoSuchProviderException: JCE cannot authenticate the provider BC
JCE kann der Anbieter nicht authentifizieren, weil wir die Verschlüsselungs Signaturen gelöscht haben indem Sie den Vorschlag an anderer Stelle in diesem selben Thread .
Die Lösung fand ich war das ausführbare Packer Plugin, das ein Glas-in-Glas verwendet Ansatz erhalten die BouncyCastle Unterschrift in einem einzigen ausführbaren Glas.
UPDATE :
Eine andere Möglichkeit, diese (die richtige Art und Weise?) Zu tun ist, um Maven Jar signer zu verwenden . Auf diese Weise können Sie Sicherheitsfehler mit Maven Schatten halten, ohne zu bekommen. Allerdings müssen Sie ein Codesignaturzertifikat verfügen (Oracle für "Java Code Signing Certificate", schlägt die Suche). Die POM Config sieht wie folgt aus:
<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>
Nein, es gibt keine Möglichkeit JCE zu bekommen ein selbst signiertes Zertifikat zu erkennen, wenn Sie also die BouncyCastle certs bewahren müssen, müssen Sie entweder das Glas-in-Glas-Plugin verwenden oder einen JCE cert zu bekommen.
Angenommen, Sie Ihre JAR-Datei mit ant bauen, können Sie einfach anweisen, die Ameise META-INF dir auslassen. Dies ist eine vereinfachte Version meiner ant Ziel:
<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>
ich vor dem gleichen Problem, nach dem Referenz irgendwo, es hat funktioniert, wie unten zu ändern:
<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>
Ich habe mit IntelliJ auf meinen Projekten vor kurzem begonnen. Jedoch verwenden einige meiner Kollegen noch von Eclipse auf den gleichen Projekten. Heute habe ich die gleichen Fehler bekam nach der jar-Datei von meinem IntelliJ erstellt ausführt. Während alle Lösungen hier in über fast die gleiche Sache sprechen, keiner von ihnen arbeitete für mich leicht (vielleicht weil ich ANT nicht verwenden, Maven Build gab mir andere Fehler, die mir genannt http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException , und auch ich konnte nicht herausfinden, was sind die signierten Gläser von mir!)
Schließlich diese mir geholfen,
zip -d demoSampler.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*SF'
Ratet mal, was aus meiner JAR-Datei entfernt ist schon?!
deleting: META-INF/ECLIPSE_.SF
deleting: META-INF/ECLIPSE_.RSA
Es scheint, dass das Problem auf einige Eclipse-relevanten Dateien relevant war.
Vergleichen Sie den Ordner META-INF in neuem Glas mit dem alten Glas (bevor Sie neue Bibliotheken hinzugefügt). Es besteht die Möglichkeit, dass es neue Dateien sein. Wenn ja, können Sie sie entfernen. Es sollte hilft. Grüße, 999michal
Fehler: Ein JNI Fehler aufgetreten ist, geben Sie bitte Ihre Installation überprüfen und versuchen Sie es erneut Ausnahme im Thread „main“ java.lang.SecurityException: Ungültige Signaturdatei digest für Manifest Hauptattribute bei sun.security.util.SignatureFileVerifier.processImpl (SignatureFileVerifier.java:314) bei sun.security.util.SignatureFileVerifier.process (SignatureFileVerifier.java:268) bei java.util.jar.JarVerifier.processEntry (JarVerifier.java:316) bei java.util.jar.JarVerifier.update (JarVerifier.java:228) bei java.util.jar.JarFile.initializeVerifier (JarFile.java:383) bei java.util.jar.JarFile.getInputStream (JarFile.java:450) bei sun.misc.URLClassPath $ JarLoader $ 2.getInputStream (URLClassPath.java:977) bei sun.misc.Resource.cachedInputStream (Resource.java:77) bei sun.misc.Resource.getByteBuffer (Resource.java:160) bei java.net.URLClassLoader.defineClass (URLClassLoader.java:454) bei java.net.URLClassLoader.access $ 100 (URLClassLoader.java:73) bei java.net.URLClassLoader $ 1.run (URLClassLoader.java:368) bei java.net.URLClassLoader $ 1.run (URLClassLoader.java:362) bei java.security.AccessController.doPrivileged (native Methode) bei java.net.URLClassLoader.findClass (URLClassLoader.java:361) bei java.lang.ClassLoader.loadClass (ClassLoader.java:424) bei sun.misc.Launcher $ AppClassLoader.loadClass (Launcher.java:331) bei java.lang.ClassLoader.loadClass (ClassLoader.java:357) bei sun.launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)
Was half mir (IntelliJ IDEA 2016,3): Datei -> Projektstruktur -> Artifacts -> Add JAR -> Wählen Sie Hauptklasse -> Wählen Sie "Kopie in das Ausgabeverzeichnis und Link über manifest" -> OK -> Bewerbung -> Build -> Build Artefakte ... -> Build
Falls Sie gradle verwenden, hier ist eine vollständige farJar Aufgabe:
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
}
Es ist möglich, dass zwei verschiedene signers mess up java Geist.
Versuchen Ordner META-INF aus Glas zu entfernen, das Hinzufügen manifestiert und wieder JAR Unterzeichnung, es half mir: http://jehy.ru/articles/2013/12/13/invalid-signature-file-digest-for-manifest-main-attributes/
würde eine Strategie bestehen ANT bei der Verwendung der Entfernung der Unterschrift von jeder Jar-Datei zu vereinfachen. Es würde gehen Sie wie folgt vor:
- Kopieren des MANIFEST.MF in einer temporären Datei
- Entfernen des Name und SHA Einträge aus der temporären Datei
- eine temporäre Jar-Datei mit dem temporären Manifest Erstellen
- Entfernen der temporären Manifest
- Swapping die ursprüngliche Jar-Datei mit den temporären einem
Hier ist ein ANT macrodef macht die Arbeit:
<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>
`
Die Definition kann dann auf diese Weise in einer ANT-Task aufgerufen werden:
<target name="unsignJar">
<unsignjar jarFile="org.test.myjartounsign.jar" />
</target>
Wenn Sie sich für eine Fat JAR-Lösung suchen, ohne Auspacken oder mit den ursprünglichen Bibliotheken Manipulationen aber mit einem speziellen JAR-Classloader, werfen Sie einen Blick auf mein Projekt hier .
Disclaimer:. Ich habe den Code nicht schreiben, nur um es verpacken und veröffentlichen sie auf Maven Zentrale und in meinem beschreiben schreib mir, wie es zu benutzen
Ich persönlich benutze es für die Erstellung von runnable uber JAR-Dateien enthalten, BouncyCastle Abhängigkeiten. Vielleicht ist es nützlich, auch für Sie.
Ich hatte das gleiche Problem in gradle wenn ein fettes Jar erstellen, die build.gradle Datei mit einer Ausschluss Linie Aktualisierung korrigierte das Problem.
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'
}
}
Für diejenigen, die Probleme mit der akzeptierten Lösung haben, gibt es eine andere Art und Weise mit DontIncludeResourceTransformer Ressource von schattierte Glas auszuschließen:
<transformers>
<transformer implementation="org.apache.maven.plugins.shade.resource.DontIncludeResourceTransformer">
<resource>BC1024KE.DSA</resource>
</transformer>
</transformers>
Von Shade 3.0 nimmt dieser Transformator eine Liste von Ressourcen. Zuvor müssen Sie nur mehrere Transformator mit jeweils einer Ressource verwendet wird.
Ich hatte ein ähnliches Problem. Der Grund war, dass ich mit einer anderen JRE als der Standard in meinem Windows-Rechner mit einem JDK kompilieren.
Mit der richtigen java.exe meinem Problem gelöst.
Wenn Sie dies, wenn ich versuchen JAR-Dateien für ein Xamarin.Android Bindungen Projekt zu binden, etwa so:
JARTOXML: Warnung J2XA006: fehlende Klasse Fehler ausgelöst wurde, während com.your.class reflektieren: Ungültige Signaturdatei für Manifest Hauptattribute verdauen
Sie die JAR-Dateien mit Winzip öffnen und löschen Sie die META-INF-Verzeichnisse. Rebuild - fertig
