#9 Fix to avoid StackOverflowException when executing a signed one-jar jar

Unstable (example)
open
nobody
None
5
2013-09-20
2013-09-20
Mark Sinke
No

We love this project. It's small, and does the job well. However, we've run into a small problem with the 0.97.1 code base.

We use one-jar to create single executable jar files for command line tools we build. To be able to check against tampering with the file, we sign it (in addition we sign the jars inside the one-jar too...). The 0.97.1 code base does not correctly handle the situation:
* when a JAR URL is resolved, the code hits OneJarFile.getJarEntry()
* when trying to read an embedded JAR file, it starts up the JarVerifier (because a .RSA and .SF file exist in the main JAR
* the JarVerifier tries to read the manifest from the top-level JAR, which triggers the getJarEntry() method, which in turn tries to open the embedded JAR file, and this closes the circle.

I have attached a patch that remedies this situation. All unit tests still work. I found no logical place or way to add a test for this scenario though. Hence the patch just references the main line code changes.

Discussion

  • Mark Sinke
    Mark Sinke
    2013-09-20

    In addition, when the fix was made to correctly resolve the MANIFEST.MF from the outer jar, I ran into an issue that may be related to JDK 7: the synthesized JarEntry that is created has no size, and the JDK (the JarFile class itself) reads the manifest in one swoop into a byte array, making use of the size of the size. That threw a NegativeArraySizeException. I fixed it by using the code to read the manifest from down in the file to compute the size (only).

     
  • Mark Sinke
    Mark Sinke
    2013-09-20

    Here's the patch as an attachment. It is really only about 10 lines of code that change.