0

The question is why is jarsigner sometimes overwriting the MANIFEST.MF file rather than just appending the signing entries to an existing MANIFEST.MF file in the jar that is being signed.

Note: I post this as an open ended question and will provide an answer or observation to one situation that I had that cause this problem. If there are other situations or circumstance in which this can happen hopefully others will expand on the posted question.

Tom Rutchik
  • 1,183
  • 1
  • 12
  • 15

2 Answers2

2

Here's one situation I saw. I have a gradle build that builds both a debug and release signed jar that is created by using jarsigner. The debug jar was signed by the default "debug.keystore" provided by android studio and the release jar was signed by my private keystore. For practical purposes the two jars are pretty much identical. Both contained the identical META-INF/MANIFEST.MF entry. The jarsigner for the debug jar overwrote the MANIFEST.MF entry. It only contained the signing entries. On the other hand, the jarsigner for the release jar appended the signing entries to the end of the existing MANIFEST.MF file as expected. Just for fun, I made a copy of the "debug.keystore" and renamed it and tried using it instead for the keystore. The manifest file was still overwritten. I then made a private keystore and created it with the same keyalias, cn, o, ou, as contained in the debug.keystore. This time the manifest file was appended to rather than being overwritten. That seems to imply that there is something related to the keystore itself that determines whether the MANIFEST.MF file is overwritten or not. Weird, but that's what I observed.

With some further investigation I discovered that my original MANIFEST.MF file did not contain a "Manifest-Version" header entry. So I added the entry and tried things again signing the debug jar with the original "debug.keystore". This time both jars appended the signing entries to the end of the existing MANIFEST.MF file rather than the debug jar overriding the MANIFEST.MF file. From that observation, we can all say, that makes sense; but who would have thought that. I certainly could not find that behavior documented anywhere.

Tom Rutchik
  • 1,183
  • 1
  • 12
  • 15
0

ugh, my own 2 cents to the matter is that simply upgrading jarsigner plugin to version 3.0.0 solved the problem (original manifest entries are kept intact)

in pom.xml:

...
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jarsigner-plugin</artifactId>
                <version>3.0.0</version>
                <executions>
                    <execution>
                        <id>sign</id>
                        <goals>
                            <goal>sign</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <keystore>mykeystore.jks</keystore>
                    <alias>myalias</alias>
                    <storepass>password</storepass>
                    <keypass>password</keypass>
                </configuration>
            </plugin>
...

Of course, other problems might still follow - e.g. in my case ClassNotFoundException was still thrown - because it turned out that there were some bouncycastle .SF and .DSA files included into my JAR's META-INF folder, carried from bouncycastle signed JARs by the shade plugin - they were interfering with the later signing I did with jarsigner plugin, causing this error when running the resulting jar with java -jar myjar.jar

hello_earth
  • 1,442
  • 1
  • 25
  • 39