"Ungültige Signaturdatei" beim Versuch, eine JAR-Datei auszuführen

Mein Java-Programm ist in einer JAR-Datei verpackt und verwendet eine externe JAR-Bibliothek, eine Hüpfburg . Mein Code wird gut kompiliert, aber das Ausführen des JAR führt zu folgendem Fehler:

Ausnahme im Thread "main" java.lang.SecurityException: Ungültiger Digest der Signaturdatei für Manifest-Hauptattribute

Ich habe über eine Stunde lang gegoogelt und nach einer Erklärung gesucht und sehr wenig Wert gefunden. Wenn jemand diesen Fehler schon einmal gesehen hat und Hilfe anbieten könnte, wäre ich verpflichtet.

Die hier aufgeführte Lösung bietet möglicherweise einen Zeiger.

Ungültiger Digest der Signaturdatei für Manifest-Hauptattribute

Endeffekt :

Es ist wahrscheinlich am besten, das offizielle JAR unverändert zu lassen und es einfach als Abhängigkeit in die Manifestdatei für Ihre Anwendungs-JAR-Datei einzufügen.

Für diejenigen, die diesen Fehler beim Erstellen eines Uber-JAR mit erhalten haben maven-shade-plugin, besteht die Lösung darin, Manifest-Signaturdateien auszuschließen, indem der Plugin-Konfiguration die folgenden Zeilen hinzugefügt werden:

<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 diejenigen, die gradle verwenden und versuchen, ein Fettglas zu erstellen und zu verwenden, kann die folgende Syntax hilfreich sein.

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 sind wahrscheinlich signierte Jarfiles. Wenn Sie sie alle zu einer großen Jarfile kombinieren, sind die entsprechenden Signaturdateien immer noch vorhanden und stimmen nicht mehr mit der "großen kombinierten" Jarfile überein, sodass die Laufzeit anhält und denkt, dass die JAR-Datei manipuliert wurde (was sie ... muss) sprechen).

Sie können das Problem lösen, indem Sie die Signaturdateien aus Ihren Jarfile-Abhängigkeiten entfernen. Leider ist es nicht möglich, dies in einem Schritt in ant zu tun .

Ich konnte dies jedoch in zwei Schritten mit Ant zum Laufen bringen, ohne jede Jarfile-Abhängigkeit speziell zu benennen, indem ich Folgendes verwendete:

<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>

Das Schlafelement soll in Zukunft Fehler bei Dateien mit Änderungsdaten verhindern .

Andere Variationen, die ich in den verknüpften Threads gefunden habe, haben bei mir nicht funktioniert.

Bitte benutzen Sie den folgenden Befehl

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

Ich hatte dieses Problem bei der Verwendung von IntelliJ IDEA 14.01.

Ich konnte es beheben durch:

Datei-> Projektstruktur-> Neue hinzufügen (Artefakte) -> jar-> Von Modulen mit Abhängigkeiten vom Fenster Jar aus Modul erstellen:

Wählen Sie Ihre Hauptklasse

JAR-Datei aus Bibliotheken Wählen Sie Kopie in das Ausgabeverzeichnis und verknüpfen Sie sie über das Manifest

Sicherheit ist bereits ein schwieriges Thema, aber ich bin enttäuscht zu sehen, dass die beliebteste Lösung darin besteht, die Sicherheitssignaturen zu löschen. JCE benötigt diese Signaturen . Maven-Schatten explodiert in der BouncyCastle-JAR-Datei, in der die Signaturen in META-INF abgelegt werden. Die BouncyCastle-Signaturen gelten jedoch nicht für ein neues Uber-JAR (nur für das BC-JAR). Dies führt zu dem ungültigen Signaturfehler in diesem Thread .

Ja, das Ausschließen oder Löschen der von @ruhsuzbaykus vorgeschlagenen Signaturen lässt zwar den ursprünglichen Fehler verschwinden, kann aber auch zu neuen, kryptischen Fehlern führen:

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

Indem Sie explizit angeben, wo sich der Algorithmus wie folgt befindet:

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

Ich konnte einen anderen Fehler bekommen:

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

JCE kann den Anbieter nicht authentifizieren, da wir die kryptografischen Signaturen gelöscht haben, indem wir dem Vorschlag an anderer Stelle in demselben Thread gefolgt sind .

Die Lösung, die ich gefunden habe, war das ausführbare Packer- Plugin, das einen JAR-in-JAR-Ansatz verwendet, um die BouncyCastle-Signatur in einem einzelnen ausführbaren JAR beizubehalten.

AKTUALISIEREN :

Eine andere Möglichkeit, dies zu tun (die richtige?), Ist die Verwendung des Maven Jar-Unterzeichners . Auf diese Weise können Sie Maven Shadow weiterhin verwenden, ohne Sicherheitsfehler zu erhalten. Sie müssen jedoch über ein Codesignaturzertifikat verfügen (Oracle schlägt vor, nach "Java Code Signing Certificate" zu suchen). Die POM-Konfiguration sieht folgendermaßen 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 dazu zu bringen, ein selbstsigniertes Zertifikat zu erkennen. Wenn Sie also die BouncyCastle-Zertifikate aufbewahren müssen, müssen Sie entweder das jar-in-jar-Plugin verwenden oder ein JCE-Zertifikat erwerben.

Ich hatte das gleiche Problem, nachdem ich irgendwo darauf hingewiesen hatte, dass es wie folgt funktioniert hat:

<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>

Angenommen, Sie erstellen Ihre JAR-Datei mit ant, können Sie ant einfach anweisen, das META-INF-Verzeichnis wegzulassen. Dies ist eine vereinfachte Version meines Ameisenziels:

<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 habe kürzlich begonnen, IntelliJ für meine Projekte zu verwenden. Einige meiner Kollegen verwenden Eclipse jedoch immer noch für dieselben Projekte. Heute habe ich den gleichen Fehler, nachdem ich die von meinem IntelliJ erstellte JAR-Datei ausgeführt habe. Während alle Lösungen hier über fast dasselbe sprachen, funktionierte keine von ihnen problemlos für mich (möglicherweise, weil ich ANT nicht verwende, gab mir maven build andere Fehler, die mich auf http://cwiki.apache.org/ verwiesen). Konfluenz / Anzeige / MAVEN / MojoExecutionException , und ich konnte auch nicht selbst herausfinden, was die signierten Gläser sind!)

Schließlich hat mir das geholfen

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

Ratet mal, was aus meiner JAR-Datei entfernt wurde?!

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

Es scheint, dass das Problem für einige Eclipse-relevante Dateien relevant war.

Ich hatte das gleiche Problem gradlebeim Erstellen eines fetten Jar. Durch Aktualisieren der build.gradleDatei mit einer Ausschlusszeile wurde das Problem behoben.

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 den Fall, dass Sie gradle verwenden, finden Sie hier 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
}

Vergleichen Sie den Ordner META-INF im neuen Glas mit dem alten Glas (bevor Sie neue Bibliotheken hinzugefügt haben). Es ist möglich, dass es neue Dateien gibt. Wenn ja, können Sie sie entfernen. Es sollte helfen. Grüße, 999michal

Eine Strategie würde darin bestehen, ANT zu verwenden, um das Entfernen der Signatur aus jeder Jar-Datei zu vereinfachen. Es würde mit den folgenden Schritten fortfahren:

1. Kopieren der Datei MANIFEST.MF in eine temporäre Datei
2. Entfernen der Einträge Name und SHA aus der temporären Datei
3. Erstellen einer temporären Jar-Datei mit dem temporären Manifest
4. Entfernen des temporären Manifests
5. Tauschen Sie die ursprüngliche Jar-Datei gegen die temporäre aus

Hier ist ein ANT-Makrodef , der die Arbeit erledigt :

<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 in einer ANT-Aufgabe folgendermaßen aufgerufen werden:

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

Fehler: Es ist ein JNI-Fehler aufgetreten. Überprüfen Sie Ihre Installation und versuchen Sie es erneut. Ausnahme im Thread "main" java.lang.SecurityException: Ungültiger Digest der Signaturdatei für Manifest-Hauptattribute unter sun.security.util.SignatureFileVerifier.processImpl (SignatureFileVerifier.java: 314) at sun.security.util.SignatureFileVerifier.process (SignatureFileVerifier.java:268) at java.util.jar.JarVerifier.processEntry (JarVerifier.java:316) at java.util.jar.JarVerifier.update (JarVerifier.java) : 228) unter java.util.jar.JarFile.initializeVerifier (JarFile.java:383) unter java.util.jar.JarFile.getInputStream (JarFile.java:450) unter 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) unter java.net.URLClassLoader.defineClass (URLClassLoader.java:454) unter java.net.URLClassLoader.access $ 100 (URLClassLoader.java:73) unter java.net.URLClassLoader $ 1.run (URLClassLoader.java:368) um 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.loadC (ClassLoader.java:424) unter sun.misc.Launcher $ AppClassLoader.loadClass (Launcher.java:331) unter java.lang.ClassLoader.loadClass (ClassLoader.java:357) unter sun.launcher.LauncherHelper.checkAndLoadMain (LauncherHper. Java: 495)Führen Sie (URLClassLoader.java:368) unter java.net.URLClassLoader $ 1.run (URLClassLoader.java:362) unter java.security.AccessController.doPrivileged (native Methode) unter java.net.URLClassLoader.findClass (URLClassLoader.java:36 aus ) 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)Führen Sie (URLClassLoader.java:368) unter java.net.URLClassLoader $ 1.run (URLClassLoader.java:362) unter java.security.AccessController.doPrivileged (native Methode) unter java.net.URLClassLoader.findClass (URLClassLoader.java:36 aus ) 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)331) unter java.lang.ClassLoader.loadClass (ClassLoader.java:357) unter sun.launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)331) unter java.lang.ClassLoader.loadClass (ClassLoader.java:357) unter sun.launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)

Was mir geholfen hat (IntelliJ IDEA 2016.3): Datei -> Projektstruktur -> Artefakte -> JAR hinzufügen -> Hauptklasse auswählen -> Wählen Sie "In das Ausgabeverzeichnis kopieren und über Manifest verknüpfen" -> OK -> Übernehmen -> Erstellen - > Artefakte erstellen ... -> Erstellen

Es ist möglich, dass zwei verschiedene Unterzeichner den Java-Verstand durcheinander bringen.

Versuchen Sie, den META-INF-Ordner aus dem JAR zu entfernen, das Manifest hinzuzufügen und JAR erneut zu signieren. Dies hat mir geholfen: http://jehy.ru/articles/2013/12/13/invalid-signature-file-digest-for-manifest-main- Attribute /

Wenn Sie nach einer Fat JAR-Lösung suchen, ohne die Originalbibliotheken zu entpacken oder zu manipulieren, aber mit einem speziellen JAR-Klassenladeprogramm, schauen Sie sich mein Projekt hier an .

Haftungsausschluss: Ich habe den Code nicht geschrieben, sondern nur verpackt und auf Maven Central veröffentlicht und in meinem Read-Me beschrieben, wie er verwendet wird.

Ich persönlich verwende es zum Erstellen von ausführbaren JARs, die BouncyCastle-Abhängigkeiten enthalten. Vielleicht ist es auch für Sie nützlich.

Für diejenigen, die Probleme mit der akzeptierten Lösung haben, gibt es eine andere Möglichkeit, Ressourcen mit DontIncludeResourceTransformer aus dem schattierten Glas auszuschließen:

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>

Ab Shade 3.0 akzeptiert dieser Transformator eine Liste von Ressourcen. Vorher müssen Sie nur mehrere Transformatoren mit jeweils einer Ressource verwenden.

Dies ist mir in Intellij passiert, als ich unter dem Strich auf "Als Maven-Projekt hinzufügen" geklickt habe, als Intellij "Nicht verwaltete POM-Dateien gefunden" sagte. Inzwischen wurde bereits ein Ordner generiert. Es wurden also keine Änderungen vorgenommen.

Das Löschen des Ordners und das Ausführen des Programms lösten das Problem für mich. Der Ordner out wurde dann neu erstellt.

Siehe auch die Antwort von Little Fox. Der Fehler, den ich erhielt, war seinem sehr ähnlich.

Ich hatte ein ähnliches Problem. Der Grund war, dass ich mit einem JDK mit einer anderen JRE als der Standard-JRE in meiner Windows-Box kompilierte.

Die Verwendung der richtigen java.exe hat mein Problem gelöst.

Wenn Sie dies erhalten, wenn Sie versuchen, JAR-Dateien für ein Xamarin.Android-Bindungsprojekt wie folgt zu binden:

JARTOXML: Warnung J2XA006: Fehlender Klassenfehler wurde ausgelöst, während com.your.class reflektiert wurde: Ungültiger Digest der Signaturdatei für Manifest-Hauptattribute

Öffnen Sie einfach die JAR-Dateien mit Winzip und löschen Sie die Meta-Inf-Verzeichnisse. Wiederaufbau - Arbeit erledigt