"Invalid signature file" when attempting to run a .jar

Question

My java program is packaged in a jar file and makes use of an external jar library, bouncy castle. My code compiles fine, but running the jar leads to the following error:

Exception in thread "main" java.lang.SecurityException: Invalid signature file digest for Manifest main attributes

I've googled for over an hour searching for an explanation and found very little of value. If anyone has seen this error before and could offer some help, I would be obliged.

are you trying to sign your own jar? if so, how are you attempting to sign it? — Cogsy, Jun 16 '09 at 03:53
No, at least I don't think I am. Xcode may be attempting to sign it on its own, but there doesn't appear to be any setting to turn this off. — , Jun 16 '09 at 04:35
don't forget to check if jars containing implemented interfaces are also signed! — Gaurav, Mar 19 '20 at 17:30
Just opened the jar with 7zip, deleted the .SF files. I did not have any .RSA files to delete — Soner from The Ottoman Empire, Jul 07 '22 at 14:57

score 1198 · Answer 1 · edited May 25 '23 at 13:21

1198

For those who got this error when trying to create a shaded uber-jar with maven-shade-plugin, the solution is to exclude manifest signature files by adding the following lines to the plugin configuration:

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

edited May 25 '23 at 13:21

hadeneh

111
1
7

answered Jul 19 '11 at 07:25

ruhsuzbaykus

13,240
2
20
21

11

I used this method for my uber-jar, and it worked great. There is a full POM example at http://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html that shows this method filtering the included files. – sourcenouveau Sep 28 '11 at 13:28
5

I was tempted to start a whole new thread - but since this is number 1 in Googles results - it seemed apt to keep it here. The lines listed here are in the POM file I am using - and I am still getting the security error when running the application. It builds fine - and of course runs fine when NOT doing an Uber jar - as expected. And while that is Certainly an option - keep them separate - it doesn't solve the issue if you want an Uber Jar. – Gavin Baumanis May 17 '16 at 09:19
9

This works for me but...why did we have to ignore the signature files? Im sure signature manifest are there for a reason.... – Jeryl Cook May 15 '17 at 21:23
7

Make sure to do "mvn clean" after doing above! – codeinjuice Aug 27 '18 at 19:26
8

@JerylCook The signature files are there to indicate that the contents of this jar have these files. When you make an uber jar, you're adding a bunch more files to the jar, and thus the signature is not correct. If you really wanted, you could re-sign the new jar, but of course it would be with your signature, not the old one. Alternatively, you could not distribute the uber jar, but instead include the signed jar as a separate file, but then that defeats the purpose of an uber jar in the first place. – LadyCailin Jan 22 '19 at 12:45
@LadyCailin Thank you for that info. That's so useful that I encourage you to edit this answer to include that explanation! – Kevin Workman Sep 13 '20 at 04:00
FWIW appears you only have to exclude the `*.SF` files, then it works... – rogerdpack Nov 24 '20 at 18:43
This doesn't really explain what is wrong with the signatures in the first place unless I missed something. In my case I need to sign my uber jar so I can't remove the signatures but I still get the exception – Michael Starkie Mar 01 '23 at 23:47

score 158 · Answer 2 · answered Jan 21 '13 at 15:15

158

For those using gradle and trying to create and use a fat jar, the following syntax might help.

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

answered Jan 21 '13 at 15:15

Keith P

2,150
1
18
15

1

This just basically excludes all files with extensions of .RSA, .SF, or .DSA inside the META-INF directory. – Keith P Nov 12 '13 at 14:42
9

Signing a jar file adds these files under META-INF, but when they are included, the signatures no longer agree with the jar contents. Thus removing them avoids the signature mismatch. – Peter N. Steinmetz Apr 04 '14 at 23:54
I am wondering if there is a way to disable those checkings on the eclipse side ? – Bionix1441 Jul 29 '15 at 12:23
what if you don't want **all** compile dependencies? – Thufir Mar 12 '16 at 09:26
1

There is a similar question strictly about using fat jar in gradle - http://stackoverflow.com/questions/4871656/using-gradle-to-build-a-jar-with-dependencies – Tomasz Sętkowski Apr 06 '16 at 18:45
4

This didn't work for me. I had to put the `exclude` to my `fatJar` task, which had that `configurations.compile.collect` command. See http://stackoverflow.com/a/31426413/103412 – Torsten May 10 '16 at 08:50
2

This solves also the error `Error: Could not find or load main class App Caused by: java.lang.ClassNotFoundException: App` – vonox7 Nov 18 '19 at 17:22

score 79 · Answer 3 · edited May 03 '21 at 23:43

79

Please use the following command

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

edited May 03 '21 at 23:43

sikander

2,286
16
23

answered Jun 09 '16 at 17:03

Peter2711

839
9
9

4

Thank you, I had this problem with intellij 14 and your solution works for me! – Mohamad Kouhi Moghadam Oct 27 '16 at 10:50
7

Thank you, worked for me in Windows. Just opened the jar with 7zip, deleted the .SF files. I did not have any .RSA files to delete – candino Mar 22 '17 at 08:44
3

Wow, can I just say this solution was amazing (and I learned something very powerful along the way!) This needs more upvoting. – Dylan_Larkin Dec 06 '17 at 18:55
I agree with the comment of @Dylan_Larkin, this is what solved it for me. – Felipe Valdes Nov 24 '18 at 17:40
1

should be zip -d yourjar.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*DSA' – StefanMK Nov 03 '20 at 16:46

score 63 · Answer 4 · edited Nov 11 '20 at 17:48

Some of your dependencies are likely signed jarfiles. When you combine them all into one big jarfile, the corresponding signature files are still present, and no longer match the "big combined" jarfile, so the runtime halts thinking the jar file has been tampered with (which it...has so to speak).

Assuming you're using ant, you can solve the problem by eliminating the signature files from your jarfile dependencies. Unfortunately, it's not possible to do this in one step in ant.

However, I was able to get this working with Ant in two steps, without specifically naming each jarfile dependency, by using:

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

The sleep element is supposed to prevent errors about files with modification dates in the future.

Other variations I found in the linked threads didn't work for me.

It's possible to do in one step, using a different way to specify your jars: — DieterDP, Apr 16 '13 at 12:13

score 48 · Accepted Answer · edited Jun 03 '13 at 21:51

48

The solution listed here might provide a pointer.

Invalid signature file digest for Manifest main attributes

Bottom line :

It's probably best to keep the official jar as is and just add it as a dependency in the manifest file for your application jar file.

edited Jun 03 '13 at 21:51

Gray

115,027
24
293
354

answered Jun 16 '09 at 04:09

Nrj

6,723
7
46
58

3

How would I reflect this in the manifest file? I've never edited one before. I'm using Xcode, and the common convention is to put external jar libraries in the myproject/lib directory for inclusion, which is what I am doing. – Jun 16 '09 at 04:35
@user123003 .. as is the case with Intelli-J – Michael M Jul 05 '14 at 02:56
14

Unfortunately some of us use things like "maven shade plugin" so including verbatim copies of the original jar is not as easy in those cases... – rogerdpack Jun 11 '15 at 18:26
shameless plug to answer on *this* site: https://stackoverflow.com/a/30922181/448779 – foo Jun 21 '17 at 19:35
what about maven-assembly-plugin? It resolve this issue in my case – jhenya-d May 22 '18 at 12:30
If you need to find out which of your direct and transitive dependencies are signed, you can do this: `mvn dependency:copy-dependencies` This will copy all the dependencies into `target/dependency`, then cd into that directory and run: `for j in `ls *.jar`; do jar tvf $j | grep -E 'META-INF/.+\.DSA|META-INF/.+\.SF|META-INF/.+\.RSA' && echo $j; done` – Chris Wolf Nov 25 '20 at 02:32
If you need to find out which of your direct and transitive dependencies are signed, you can do this: `mvn dependency:copy-dependencies` This will copy all the dependencies into `target/dependency`, then cd into that directory and run: `for j in $(ls *.jar); do jar tvf $j | grep -E 'META-INF/.+\.DSA|META-INF/.+\.SF|META-INF/.+\.RSA' && echo $j; done` – Chris Wolf Nov 25 '20 at 02:40

MattW · Answer 6 · 2017-09-05T22:16:47.527

Security is already a tough topic, but I'm disappointed to see the most popular solution is to delete the security signatures. JCE requires these signatures. Maven shade explodes the BouncyCastle jar file which puts the signatures into META-INF, but the BouncyCastle signatures aren't valid for a new, uber-jar (only for the BC jar), and that's what causes the Invalid signature error in this thread.

Yes, excluding or deleting the signatures as suggested by @ruhsuzbaykus does indeed make the original error go away, but it can also lead to new, cryptic errors:

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

By explicitly specifying where to find the algorithm like this:

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

I was able to get a different error:

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

JCE can't authenticate the provider because we've deleted the cryptographic signatures by following the suggestion elsewhere in this same thread.

The solution I found was the executable packer plugin that uses a jar-in-jar approach to preserve the BouncyCastle signature in a single, executable jar.

UPDATE:

Another way to do this (the correct way?) is to use Maven Jar signer. This allows you to keep using Maven shade without getting security errors. HOWEVER, you must have a code signing certificate (Oracle suggests searching for "Java Code Signing Certificate"). The POM config looks like this:

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

No, there's no way to get JCE to recognize a self-signed cert, so if you need to preserve the BouncyCastle certs, you have to either use the jar-in-jar plugin or get a JCE cert.

This is definitely the right way to do it, even if it's work intensive. Thanks for pointing out, in detail, the caveats with using the approved answer. Do you know if the JCE cert has to be signed by Sun? Or can — Ebsan, Oct 18 '17 at 15:03
There are third parties that can issue code signing certs. Search for "Java Code Signing Certificate" to see options. — MattW, Oct 19 '17 at 15:34
Helped for me. There are some files in this library, that I don't use, so except them help me with fat-jar file — Saidolim, Dec 25 '19 at 16:24

score 28 · Answer 7 · answered Dec 11 '14 at 18:07

28

I had this problem when using IntelliJ IDEA 14.01.

I was able to fix it by:

File->Project Structure->Add New (Artifacts)->jar->From Modules With Dependencies on the Create Jar From Module Window:

Select you main class

JAR File from Libraries Select copy to the output directory and link via manifest

answered Dec 11 '14 at 18:07

Travis

2,105
2
26
35

2

Is it possible to put the dependent jars into the target jar? – coder.chenzhi Jun 28 '17 at 04:29

m.nguyencntt · Answer 8 · 2019-03-21T01:57:03.757

I faced the same issue, after reference somewhere, it worked as below changing:

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

This solved my issue swiftly! For completeness, this should go in the `maven-shade-plugin` tag. — Kuzeko, Mar 20 '19 at 16:00

score 8 · Answer 9 · answered Sep 05 '10 at 07:02

8

Assuming you build your jar file with ant, you can just instruct ant to leave out the META-INF dir. This is a simplified version of my ant target:

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

answered Sep 05 '10 at 07:02

Kim Stebel

41,826
12
125
142

where i should add these lines? – Addi.Star Sep 21 '19 at 10:33

score 6 · Answer 10 · answered Jun 09 '18 at 04:50

I've recently started using IntelliJ on my projects. However, some of my colleagues still use Eclipse on the same projects. Today, I've got the very same error after executing the jar-file created by my IntelliJ. While all the solutions in here talking about almost the same thing, none of them worked for me easily (possibly because I don't use ANT, maven build gave me other errors which referred me to http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException, and also I couldn't figure out what are the signed jars by myself!)

Finally, this helped me

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

Guess what's been removed from my jar file?!

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

It seems that the issue was relevant to some eclipse-relevant files.

Ahmad Al-Kurdi · Answer 11 · 2022-04-07T01:16:12.523

5

I had the same issue in gradle when creating a fat Jar; updating the build.gradle file with an exclude line corrected the 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'
    }
}

edited Apr 07 '22 at 01:16

answered Jan 16 '19 at 15:34

Ahmad Al-Kurdi

2,248
3
23
39

1

I was debugging for days, this solved my fat jar issue. – sysuser Nov 07 '19 at 00:40
The way I debugged is to put the fat jar in jmeter lib directory. If you have the problematic jar in lib/ext, this problem won't be obvious, rather you will get an error like the one in https://stackoverflow.com/questions/37624187/can-not-load-jmeter-test-plan-on-newest-jmeter-version-jmeter-protocol-java-co – sysuser Nov 07 '19 at 00:57
1

exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA' This was missing, some dependent jar was causing the issue – Nirbhay Mishra Apr 24 '20 at 05:49

score 3 · Answer 12 · answered May 11 '18 at 14:27

In case you're using gradle, here is a full farJar task:

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
}

score 2 · Answer 13 · answered Jun 02 '10 at 14:12

2

Compare the folder META-INF in new jar with old jar (before you added new libraries). It is possibility that there will be new files. If yes, you can remove them. It should helps. Regards, 999michal

answered Jun 02 '10 at 14:12

999michal

21
1

bdulac · Answer 14 · 2016-12-26T15:32:33.723

A strategy would consist in using ANT to simplify the removal of the signature from each Jar file. It would proceed with the following steps:

Copying the MANIFEST.MF in a temporary file
Removing the Name and SHA entries from the temporary file
Creating a temporary Jar file with the temporary manifest
Removing the temporary manifest
Swapping the original Jar file with the temporary one

Here is an ANT macrodef doing the work:

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

`

The definition can then be called this way in an ANT task:

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

score 2 · Answer 15 · answered Feb 11 '17 at 09:16

Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.lang.SecurityException: Invalid signature file digest for Manifest main attributes at 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) at java.util.jar.JarFile.initializeVerifier(JarFile.java:383) at java.util.jar.JarFile.getInputStream(JarFile.java:450) at sun.misc.URLClassPath$JarLoader$2.getInputStream(URLClassPath.java:977) at sun.misc.Resource.cachedInputStream(Resource.java:77) at sun.misc.Resource.getByteBuffer(Resource.java:160) at java.net.URLClassLoader.defineClass(URLClassLoader.java:454) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.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) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)

What helped me (IntelliJ IDEA 2016.3): File -> Project Structure -> Artifacts -> Add JAR -> Select Main Class -> Choose "copy to the output directory and link via manifest" -> OK -> Apply -> Build -> Build Artifacts... -> Build

score 1 · Answer 16 · answered Dec 13 '13 at 07:09

1

It's possible that two different signers mess up java mind.

Try removing META-INF folder from jar, adding manifest and signing JAR again, it helped me: http://jehy.ru/articles/2013/12/13/invalid-signature-file-digest-for-manifest-main-attributes/

answered Dec 13 '13 at 07:09

Jehy

4,729
1
38
55

1

+1 for the link. Removing META-INF\*.RSA and META-INF\*.SF from the jars I was working with solved the issues for me. YMMV – KathyA. Apr 10 '14 at 14:55

kriegaex · Answer 17 · 2018-10-14T07:37:15.990

If you are looking for a Fat JAR solution without unpacking or tampering with the original libraries but with a special JAR classloader, take a look at my project here.

Disclaimer: I did not write the code, just package it and publish it on Maven Central and describe in my read-me how to use it.

I personally use it for creating runnable uber JARs containing BouncyCastle dependencies. Maybe it is useful for you, too.

jqgsninimo · Answer 18 · 2021-04-11T14:32:48.700

You can use Shadow to generate a jar.

Shadow is a Gradle plugin for combining a project's dependency classes and resources into a single output Jar. The combined Jar is often referred to a fat-jar or uber-jar.

Modify build.gradle

plugins {
    ...
    // ① Add the shadow plugin
    id "com.github.johnrengelman.shadow" version "5.2.0"
}

...
// ② Config the shadow jar, its name is baseName-1.0-classifier.jar
shadowJar {
    archiveBaseName.set('baseName')
    archiveClassifier.set('classifier')
    archiveVersion.set('1.0')
    manifest {
        attributes 'Main-Class': 'Main'
    }
}

// ③ Disable the default jar task
jar.enabled = false
// ④ Execute the shadowJar task when compiling
build.dependsOn(shadowJar)

Execute the command gradle build, the jar file will be generated:
- <Project Directory>/build/libs/baseName-1.0-classifier.jar

score 0 · Answer 19 · answered Sep 09 '19 at 06:30

For those who have trouble with the accepted solution, there is another way to exclude resource from shaded jar with 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>

From Shade 3.0, this transformer accepts a list of resources. Before that you just need to use multiple transformer each with one resource.

score 0 · Answer 20 · answered Jan 15 '20 at 08:14

This happened to me in Intellij when I clicked "Add as a Maven Project" on bottom line when Intellij said "non-managed pom files found.". Meanwhile out folder was already generated. So it did not get recent changes.

Deleting out folder and running the program solved the issue for me. out folder was then recreated.

See the answer of Little Fox as well. The error I received was very similar to his.

score 0 · Answer 21 · answered Nov 03 '22 at 01:51

For someone who using kotlin script(kts) as building script:

task("fatJar", type = Jar::class) {
baseName = "${project.name}-fat"
manifest {
    attributes["Implementation-Title"] = "Watcher Jar File"
    attributes["Implementation-Version"] = version
    attributes["Main-Class"] = "MainKt"
}
from(configurations.runtimeClasspath.get().map { if (it.isDirectory) it else zipTree(it) }) {
    exclude(listOf("META-INF/*.RSA", "META-INF/*.SF", "META-INF/*.DSA"))
}
with(tasks.jar.get() as CopySpec)

}

score 0 · Answer 22 · answered Apr 28 '23 at 10:25

As @MattW mentioned, doing this on a JCE provider (like BouncyCastle) can cause new exceptions to occur.

Regardless, if you want to fix the error mentioned in the OP, and you use Gradle Kotlin Build Script, you can use following code to make it work:

tasks.withType<Jar> {
    excludes += listOf("META-INF/*.SF", "META-INF/*.DSA", "META-INF/*.RSA")
}

This will exclude a list of files from tasks with type "Jar", regardless of what tasks these are.

score -1 · Answer 23 · answered Aug 02 '10 at 12:54

-1

I had a similar problem. The reason was that I was compiling using a JDK with a different JRE than the default one in my Windows box.

Using the correct java.exe solved my problem.

answered Aug 02 '10 at 12:54

Jus12

17,824
28
99
157

score -3 · Answer 24 · answered Sep 23 '14 at 09:30

-3

If you're getting this when trying to bind JAR files for a Xamarin.Android bindings project like so:

JARTOXML : warning J2XA006: missing class error was raised while reflecting com.your.class : Invalid signature file digest for Manifest main attributes

Just open the JAR files using Winzip and delete the meta-inf directories. Rebuild - job done

answered Sep 23 '14 at 09:30

Dean Wild

5,886
3
38
45

2

This is a horrible technique. Absolutely Horrible. Make the corrections locally don't make changes to incoming jars – sinisterrook Jun 06 '16 at 14:16

"Invalid signature file" when attempting to run a .jar

24 Answers24

UPDATE:

Linked

Related