Re: MAS codesign requirements break Java app signing
Zach, Having mentioned this on the side, I’ll say it again for posterity: I bundle my app also using the appbundler and also have just recently been receiving that same email from Apple upon app submission. Today, I finally got my app bundle to be accepted (for the first part of the process anyhow, it’s still pending a review from a human now). Here’s what I noticed and did differently… Looking at my fully signed app bundle, I noticed that the MyApp.app/Contents/PlugIns/1.8.0.jre/Contents/_CodeSignature folder contained different items than the MyApp.app/Contents/_CodeSignature folder.. particularly, it contained a CodeResources file which made me wonder if perhaps this was what was triggering our error (as the Apple documentation mentions not using the --resource-rules flag anymore, which I was never doing in the first place, but according to the codesign documentation, if resource rules are not specified, it does its best to make something up, and I’m guessing it was making something up for my embedded JRE bundle). After some tinkering around, I discovered that the appbundler removes a particular folder, the 1.8.0.jre/Contents/MacOS folder when it stuffs the JRE into MyApp.app. Well, when this folder is removed, codesign behaves much differently than when this folder is present. When this folder is present, the MyApp.app/Contents/PlugIns/1.8.0.jre/Contents/_CodeSignature folder contains the same item as the MyApp.app/Contents/_CodeSignature folder. So, after I did my usual bundling script, I went in and manually restored the MyApp.app/Contents/PlugIns/1.8.0.jre/Contents/MacOS folder, then I signed everything as I usually do… and surely enough, the app is accepted by Application Loader. So, given that you are still struggling with javapackager, you might want to try this simple solution, as it might be all that you need to keep your existing flow working. -Jess On Nov 9, 2014, at 2:26 PM, Zach Oakes zsoa...@gmail.com wrote: It looks like Apple has changed its codesigning requirements for the Mac App Store. Thus far, I've been packaging my Java app using Oracle's appbundler tool and signing it with the following script: http://pastebin.com/BtLV9bur This worked fine even as recently as last month. This time, I get an email from them with the following: Invalid code signature - Signatures created with OS X version 10.8.5 or earlier [v1 signatures] are obsoleted and will no longer be recognized by Gatekeeper beginning with OS X version 10.9.5. To ensure your apps will run on updated versions of OS X they must be signed on OS X version 10.9 or later [v2 signatures]. For more information, see OS X Code Signing In Depth I think this error is incorrect, because I'm using 10.9.5 with the latest Xcode (6.1). I tried codesign -dv MyApp.app and it says Sealed Resources version=2 rules=12 files=7, so I think I am using v2 signatures. My JDK version has not changed since last month (8u25), so I can rule that out. I would appreciate any help. Thank you. Zach
Re: MAS codesign requirements break Java app signing
Jessica, thank you so much. Your fix worked for me, and I wouldn't have discovered it on my own. I'll try javapackager again when the next JDK update comes, but this will certainly work for the time being. Thank you to Danno, Michael, and the others as well for all the responses. Zach On Tue, Nov 11, 2014 at 4:44 PM, Jessica Finley jfin...@tech4learning.com wrote: Zach, Having mentioned this on the side, I'll say it again for posterity: I bundle my app also using the appbundler and also have just recently been receiving that same email from Apple upon app submission. Today, I finally got my app bundle to be accepted (for the first part of the process anyhow, it's still pending a review from a human now). Here's what I noticed and did differently... Looking at my fully signed app bundle, I noticed that the MyApp.app/Contents/PlugIns/1.8.0.jre/Contents/_CodeSignature folder contained different items than the MyApp.app/Contents/_CodeSignature folder.. particularly, it contained a CodeResources file which made me wonder if perhaps this was what was triggering our error (as the Apple documentation mentions not using the --resource-rules flag anymore, which I was never doing in the first place, but according to the codesign documentation, if resource rules are not specified, it does its best to make something up, and I'm guessing it was making something up for my embedded JRE bundle). After some tinkering around, I discovered that the appbundler removes a particular folder, the 1.8.0.jre/Contents/MacOS folder when it stuffs the JRE into MyApp.app. Well, when this folder is removed, codesign behaves much differently than when this folder is present. When this folder is present, the MyApp.app/Contents/PlugIns/1.8.0.jre/Contents/_CodeSignature folder contains the same item as the MyApp.app/Contents/_CodeSignature folder. So, after I did my usual bundling script, I went in and manually restored the MyApp.app/Contents/PlugIns/1.8.0.jre/Contents/MacOS folder, then I signed everything as I usually do... and surely enough, the app is accepted by Application Loader. So, given that you are still struggling with javapackager, you might want to try this simple solution, as it might be all that you need to keep your existing flow working. -Jess On Nov 9, 2014, at 2:26 PM, Zach Oakes zsoa...@gmail.com wrote: It looks like Apple has changed its codesigning requirements for the Mac App Store. Thus far, I've been packaging my Java app using Oracle's appbundler tool and signing it with the following script: http://pastebin.com/BtLV9bur This worked fine even as recently as last month. This time, I get an email from them with the following: Invalid code signature - Signatures created with OS X version 10.8.5 or earlier [v1 signatures] are obsoleted and will no longer be recognized by Gatekeeper beginning with OS X version 10.9.5. To ensure your apps will run on updated versions of OS X they must be signed on OS X version 10.9 or later [v2 signatures]. For more information, see OS X Code Signing In Depth I think this error is incorrect, because I'm using 10.9.5 with the latest Xcode (6.1). I tried codesign -dv MyApp.app and it says Sealed Resources version=2 rules=12 files=7, so I think I am using v2 signatures. My JDK version has not changed since last month (8u25), so I can rule that out. I would appreciate any help. Thank you. Zach
Re: MAS codesign requirements break Java app signing
Darn. Is there no way to manually insert values into the Info.plist before it is signed? If not, I guess I'll keep trying to get my custom script to work. I just need some kind of short term solution to get this app update out... By the way, I noticed there is also no way to set the CFBundleVersion, so it's always set to 100. That would prevent me from using the tool as well. Note that I am using 8u25, not 8u20. Zach On Mon, Nov 10, 2014 at 2:46 PM, Danno Ferrin danno.fer...@oracle.com wrote: This may be a bug in 8u20. By setting -Bclasspath=whatever it should be putting whatever in as the string. I'de have to dig up the code because that section of code is uner a major overhaul for 8u40 because of the new launcher work. On Nov 10, 2014, at 10:33 AM, Zach Oakes zsoa...@gmail.com wrote: I can see from the Info.plist file in the app bundle that JVMAppClasspath is an empty string: keyJVMAppClasspath/key string/string On Mon, Nov 10, 2014 at 12:27 PM, Zach Oakes zsoa...@gmail.com wrote: It looks like the classpath is always just the main jar, no matter whether I explicitly use -classPath or not. I am running System.getProperty(java.class.path) and it returns /path/to/myapp.jar and nothing else. This is the current command I'm running: javapackager -deploy -native \ -name MyApp \ -outdir out \ -outfile MyApp \ -srcdir bin \ -appclass myapp.Main \ -BappVersion=0.4.2 \ -Bicon=logo_launcher.icns \ -BmainJar=myapp.jar \ -Bmac.category=public.app-category.developer-tools \ -Bmac.CFBundleIdentifier=info.oakleaf.myapp \ -Bmac.CFBundleName=MyApp \ -Bmac.signing-key-app=3rd Party Mac Developer Application: X \ -Bmac.signing-key-pkg=3rd Party Mac Developer Installer: X \ -Bmac.app-store-entitlements=MyApp.entitlements On Mon, Nov 10, 2014 at 12:09 PM, Danno Ferrin danno.fer...@oracle.com wrote: No, the class path is either set to all the files in the srcdir, or to whatever you explicitly set it to. Since you explicitly set the class path to -BclassPath=myapp.jar:ObjCBridge.jar:jna.jar then the class path is explicitly set. Note that with the javapackager everything passed in as a resource to -srcdir and/or -srcfiles is placed in .../Contents/Java, and nowhere else. This is so it works mostly the same with Windows and linux, where those are placed in .../app. On Nov 10, 2014, at 10:06 AM, Zach Oakes zsoa...@gmail.com wrote: Oh, I didn't realize you could just put native libraries in srcdir. Is the classpath is set to .../Contents/Java as well? I have a few extra jar files my app needs to use. I can see they are copied there successfully, but I can't seem to find their classes on the classpath. On Mon, Nov 10, 2014 at 11:24 AM, Danno Ferrin danno.fer...@oracle.com wrote: Is this a verification on the part of apple? Is it that the program does not find the library? Or is it that the native library is not in the .app package at all? For 8u20, the launcher javapackager provides sets the java.library.path to be app root/Contents/Java, so a call to System.loadLibrary(jcocca) should be loading .../Contents/Java/libjcocca.dylib Is the native library in the -srcdir? On Nov 10, 2014, at 8:59 AM, Zach Oakes zsoa...@gmail.com wrote: The error is the parameter dealing with the native library, libjcocoa.dylib, that my app requires. Does javapackager support adding native libraries? It should be copied into MyApp.app/Contents/MacOS. On Mon, Nov 10, 2014 at 10:41 AM, Zach Oakes zsoa...@gmail.com wrote: Ah, forgive me, there was an error in the bundle process so it stopped short of creating a pkg. I will keep working on the parameters to see if I can fix it. On Mon, Nov 10, 2014 at 10:38 AM, Zach Oakes zsoa...@gmail.com wrote: Definitely progress! It ended up creating a bundle, but not a pkg file. Maybe it's trying to make a normal mac bundle? I am using 8u25, by the way. On Mon, Nov 10, 2014 at 10:26 AM, Danno Ferrin danno.fer...@oracle.com wrote: Try just '-native' and not '-native mac.appStore'. I think there were case checking issues in the 8u20 release. On Nov 10, 2014, at 8:25 AM, Zach Oakes zsoa...@gmail.com wrote: Danno, since you mentioned javapackager, I decided to try using it in hopes that it would solve the issue. I'm trying to put together a command for it, but it's a bit confounding. So far I'm just getting a jnlp and html file to appear. Here's what I have so far (split onto separate lines for readability): javapackager -deploy -native mac.appStore -name MyApp -outdir out -outfile MyApp -srcdir bin -appclass myapp.Main -BappVersion=0.4.2 -Bicon=logo_launcher.icns -BclassPath=myapp.jar:ObjCBridge.jar:jna.jar -Bjava.library.path=libjcocoa.dylib -Bmac.category=public.app-category.developer-tools -Bmac.CFBundleIdentifier=info.oakleaf.myapp -Bmac.CFBundleName=MyApp -Bmac.signing-key-app=3rd Party Mac Developer Application: X -Bmac.signing-key-pkg=3rd Party Mac Developer Installer:
Re: MAS codesign requirements break Java app signing
Thanks Steve, I'll try it out when I get home. I am using 10.9.5 (Mavericks), not Yosemite. I'm using different entitlements under Danno's suggestion, and it has worked so far until some time in the last month. On Mon, Nov 10, 2014 at 3:29 PM, Steve Hannah st...@weblite.ca wrote: I was just reading through your original codesign script for your infinikind bundler option, and I noticed that you are using different entitlements for the libs than for your app. I don't recall if entitlements are even required for the libs, but I have always just used the same entitlements for my libs as for my app. The script that I use is: https://gist.github.com/shannah/fb2d89592f627d67d162 I haven't tried building with Yosemite yet, so it may suffer from the same problems as yours. Steve On Mon, Nov 10, 2014 at 11:46 AM, Danno Ferrin danno.fer...@oracle.com wrote: This may be a bug in 8u20. By setting -Bclasspath=whatever it should be putting whatever in as the string. I'de have to dig up the code because that section of code is uner a major overhaul for 8u40 because of the new launcher work. On Nov 10, 2014, at 10:33 AM, Zach Oakes zsoa...@gmail.com wrote: I can see from the Info.plist file in the app bundle that JVMAppClasspath is an empty string: keyJVMAppClasspath/key string/string On Mon, Nov 10, 2014 at 12:27 PM, Zach Oakes zsoa...@gmail.com wrote: It looks like the classpath is always just the main jar, no matter whether I explicitly use -classPath or not. I am running System.getProperty(java.class.path) and it returns /path/to/myapp.jar and nothing else. This is the current command I'm running: javapackager -deploy -native \ -name MyApp \ -outdir out \ -outfile MyApp \ -srcdir bin \ -appclass myapp.Main \ -BappVersion=0.4.2 \ -Bicon=logo_launcher.icns \ -BmainJar=myapp.jar \ -Bmac.category=public.app-category.developer-tools \ -Bmac.CFBundleIdentifier=info.oakleaf.myapp \ -Bmac.CFBundleName=MyApp \ -Bmac.signing-key-app=3rd Party Mac Developer Application: X \ -Bmac.signing-key-pkg=3rd Party Mac Developer Installer: X \ -Bmac.app-store-entitlements=MyApp.entitlements On Mon, Nov 10, 2014 at 12:09 PM, Danno Ferrin danno.fer...@oracle.com wrote: No, the class path is either set to all the files in the srcdir, or to whatever you explicitly set it to. Since you explicitly set the class path to -BclassPath=myapp.jar:ObjCBridge.jar:jna.jar then the class path is explicitly set. Note that with the javapackager everything passed in as a resource to -srcdir and/or -srcfiles is placed in .../Contents/Java, and nowhere else. This is so it works mostly the same with Windows and linux, where those are placed in .../app. On Nov 10, 2014, at 10:06 AM, Zach Oakes zsoa...@gmail.com wrote: Oh, I didn't realize you could just put native libraries in srcdir. Is the classpath is set to .../Contents/Java as well? I have a few extra jar files my app needs to use. I can see they are copied there successfully, but I can't seem to find their classes on the classpath. On Mon, Nov 10, 2014 at 11:24 AM, Danno Ferrin danno.fer...@oracle.com wrote: Is this a verification on the part of apple? Is it that the program does not find the library? Or is it that the native library is not in the .app package at all? For 8u20, the launcher javapackager provides sets the java.library.path to be app root/Contents/Java, so a call to System.loadLibrary(jcocca) should be loading .../Contents/Java/libjcocca.dylib Is the native library in the -srcdir? On Nov 10, 2014, at 8:59 AM, Zach Oakes zsoa...@gmail.com wrote: The error is the parameter dealing with the native library, libjcocoa.dylib, that my app requires. Does javapackager support adding native libraries? It should be copied into MyApp.app/Contents/MacOS. On Mon, Nov 10, 2014 at 10:41 AM, Zach Oakes zsoa...@gmail.com wrote: Ah, forgive me, there was an error in the bundle process so it stopped short of creating a pkg. I will keep working on the parameters to see if I can fix it. On Mon, Nov 10, 2014 at 10:38 AM, Zach Oakes zsoa...@gmail.com wrote: Definitely progress! It ended up creating a bundle, but not a pkg file. Maybe it's trying to make a normal mac bundle? I am using 8u25, by the way. On Mon, Nov 10, 2014 at 10:26 AM, Danno Ferrin danno.fer...@oracle.com wrote: Try just '-native' and not '-native mac.appStore'. I think there were case checking issues in the 8u20 release. On Nov 10, 2014, at 8:25 AM, Zach Oakes zsoa...@gmail.com wrote: Danno, since you mentioned javapackager, I decided to try using it in hopes that it would solve the issue. I'm trying to put together a command for it, but it's a bit confounding. So far I'm just getting a jnlp and html file to appear. Here's what I have so far (split onto separate lines for readability): javapackager -deploy -native mac.appStore -name MyApp -outdir out
Re: MAS codesign requirements break Java app signing
With the Ant task, I already can manually edit my Info.plist so that's not an issue. The problem with it is simply that Apple is rejecting it after I upload the app with the error message I included in the OP. There is something wrong with the sig but I can't figure out what it is. On Mon, Nov 10, 2014 at 4:28 PM, Alan Snyder javali...@cbfiddle.com wrote: If you are using the Ant task, you may be able to get Ant to look for the resources using the classpath specified in the taskdef. However, that works only if the ant task JAR is not on Ant's classpath. It took me a while to figure that out. On Nov 10, 2014, at 1:10 PM, Danno Ferrin danno.fer...@oracle.com wrote: You can insert values into the Info,plist, it just involves some acrobatics. There is a resource replacement technique that looks for the resource on the classpath of the execution of the tool, which for the CLI includes the current directory.
Re: MAS codesign requirements break Java app signing
I successfully am replacing the Info.plist file with the technique you mentioned. Is it possible that the JVMAppClasspath key does not actually do anything? I added the extra jars to it, trying both a space and a colon as a separator, and the java.class.path is always just the main jar file. Sorry for the continuous problems... keyJVMAppClasspath/key stringObjCBridge.jar jna.jar/string On Mon, Nov 10, 2014 at 4:10 PM, Danno Ferrin danno.fer...@oracle.com wrote: You can insert values into the Info,plist, it just involves some acrobatics. There is a resource replacement technique that looks for the resource on the classpath of the execution of the tool, which for the CLI includes the current directory. There are also some peculiarities for the name. For the Info.plist it would be loaded from ./package/macosx/Info.plist. If you use the -verbose or -v option the javapackager tool will both leave the default files in a temporary directory (that it will tell you about) and tell you specifically where to put replacement files. On Nov 10, 2014, at 1:41 PM, Zach Oakes zsoa...@gmail.com wrote: Darn. Is there no way to manually insert values into the Info.plist before it is signed? If not, I guess I'll keep trying to get my custom script to work. I just need some kind of short term solution to get this app update out... By the way, I noticed there is also no way to set the CFBundleVersion, so it's always set to 100. That would prevent me from using the tool as well. Note that I am using 8u25, not 8u20. Zach On Mon, Nov 10, 2014 at 2:46 PM, Danno Ferrin danno.fer...@oracle.com wrote: This may be a bug in 8u20. By setting -Bclasspath=whatever it should be putting whatever in as the string. I'de have to dig up the code because that section of code is uner a major overhaul for 8u40 because of the new launcher work. On Nov 10, 2014, at 10:33 AM, Zach Oakes zsoa...@gmail.com wrote: I can see from the Info.plist file in the app bundle that JVMAppClasspath is an empty string: keyJVMAppClasspath/key string/string On Mon, Nov 10, 2014 at 12:27 PM, Zach Oakes zsoa...@gmail.com wrote: It looks like the classpath is always just the main jar, no matter whether I explicitly use -classPath or not. I am running System.getProperty(java.class.path) and it returns /path/to/myapp.jar and nothing else. This is the current command I'm running: javapackager -deploy -native \ -name MyApp \ -outdir out \ -outfile MyApp \ -srcdir bin \ -appclass myapp.Main \ -BappVersion=0.4.2 \ -Bicon=logo_launcher.icns \ -BmainJar=myapp.jar \ -Bmac.category=public.app-category.developer-tools \ -Bmac.CFBundleIdentifier=info.oakleaf.myapp \ -Bmac.CFBundleName=MyApp \ -Bmac.signing-key-app=3rd Party Mac Developer Application: X \ -Bmac.signing-key-pkg=3rd Party Mac Developer Installer: X \ -Bmac.app-store-entitlements=MyApp.entitlements On Mon, Nov 10, 2014 at 12:09 PM, Danno Ferrin danno.fer...@oracle.com wrote: No, the class path is either set to all the files in the srcdir, or to whatever you explicitly set it to. Since you explicitly set the class path to -BclassPath=myapp.jar:ObjCBridge.jar:jna.jar then the class path is explicitly set. Note that with the javapackager everything passed in as a resource to -srcdir and/or -srcfiles is placed in .../Contents/Java, and nowhere else. This is so it works mostly the same with Windows and linux, where those are placed in .../app. On Nov 10, 2014, at 10:06 AM, Zach Oakes zsoa...@gmail.com wrote: Oh, I didn't realize you could just put native libraries in srcdir. Is the classpath is set to .../Contents/Java as well? I have a few extra jar files my app needs to use. I can see they are copied there successfully, but I can't seem to find their classes on the classpath. On Mon, Nov 10, 2014 at 11:24 AM, Danno Ferrin danno.fer...@oracle.com wrote: Is this a verification on the part of apple? Is it that the program does not find the library? Or is it that the native library is not in the .app package at all? For 8u20, the launcher javapackager provides sets the java.library.path to be app root/Contents/Java, so a call to System.loadLibrary(jcocca) should be loading .../Contents/Java/libjcocca.dylib Is the native library in the -srcdir? On Nov 10, 2014, at 8:59 AM, Zach Oakes zsoa...@gmail.com wrote: The error is the parameter dealing with the native library, libjcocoa.dylib, that my app requires. Does javapackager support adding native libraries? It should be copied into MyApp.app/Contents/MacOS. On Mon, Nov 10, 2014 at 10:41 AM, Zach Oakes zsoa...@gmail.com wrote: Ah, forgive me, there was an error in the bundle process so it stopped short of creating a pkg. I will keep working on the parameters to see if I can fix it. On Mon, Nov 10, 2014 at 10:38 AM, Zach Oakes zsoa...@gmail.com wrote: Definitely progress! It ended up creating a bundle, but not a pkg file. Maybe it's trying to
Re: MAS codesign requirements break Java app signing
In the bash script I linked, everything but jspawnhelper gets the full (user-supplied) entitlements. Do you think that is the problem? On Sun, Nov 9, 2014 at 7:13 PM, Danno Ferrin danno.fer...@oracle.com wrote: What are your entitlements? For javapackager we sign only the master package with real user supplied entitlements, every other jar, dylib, and executable gets an entitlement with an entitlements that is just sandbox and inherit. We also don't put entitlements on the JRE package when it is signed under plugins. On Nov 9, 2014, at 2:26 PM, Zach Oakes zsoa...@gmail.com wrote: It looks like Apple has changed its codesigning requirements for the Mac App Store. Thus far, I've been packaging my Java app using Oracle's appbundler tool and signing it with the following script: http://pastebin.com/BtLV9bur This worked fine even as recently as last month. This time, I get an email from them with the following: Invalid code signature - Signatures created with OS X version 10.8.5 or earlier [v1 signatures] are obsoleted and will no longer be recognized by Gatekeeper beginning with OS X version 10.9.5. To ensure your apps will run on updated versions of OS X they must be signed on OS X version 10.9 or later [v2 signatures]. For more information, see OS X Code Signing In Depth I think this error is incorrect, because I'm using 10.9.5 with the latest Xcode (6.1). I tried codesign -dv MyApp.app and it says Sealed Resources version=2 rules=12 files=7, so I think I am using v2 signatures. My JDK version has not changed since last month (8u25), so I can rule that out. I would appreciate any help. Thank you. Zach
Re: MAS codesign requirements break Java app signing
Not sure, but that is what is different from what I have that works. Everything else seemed to match up, including the forced overriding of the signatures. On Nov 9, 2014, at 5:23 PM, Zach Oakes zsoa...@gmail.com wrote: In the bash script I linked, everything but jspawnhelper gets the full (user-supplied) entitlements. Do you think that is the problem? On Sun, Nov 9, 2014 at 7:13 PM, Danno Ferrin danno.fer...@oracle.com wrote: What are your entitlements? For javapackager we sign only the master package with real user supplied entitlements, every other jar, dylib, and executable gets an entitlement with an entitlements that is just sandbox and inherit. We also don't put entitlements on the JRE package when it is signed under plugins. On Nov 9, 2014, at 2:26 PM, Zach Oakes zsoa...@gmail.com wrote: It looks like Apple has changed its codesigning requirements for the Mac App Store. Thus far, I've been packaging my Java app using Oracle's appbundler tool and signing it with the following script: http://pastebin.com/BtLV9bur This worked fine even as recently as last month. This time, I get an email from them with the following: Invalid code signature - Signatures created with OS X version 10.8.5 or earlier [v1 signatures] are obsoleted and will no longer be recognized by Gatekeeper beginning with OS X version 10.9.5. To ensure your apps will run on updated versions of OS X they must be signed on OS X version 10.9 or later [v2 signatures]. For more information, see OS X Code Signing In Depth I think this error is incorrect, because I'm using 10.9.5 with the latest Xcode (6.1). I tried codesign -dv MyApp.app and it says Sealed Resources version=2 rules=12 files=7, so I think I am using v2 signatures. My JDK version has not changed since last month (8u25), so I can rule that out. I would appreciate any help. Thank you. Zach
Re: MAS codesign requirements break Java app signing
On Nov 9, 2014, at 6:10 PM, Zach Oakes zsoa...@gmail.com wrote: Can you elaborate on what you are trying to say? As I mentioned, I already ran codesign -dv MyApp.app, and it does indeed show version=2. Yet, I still get the error from Apple after uploading. Sorry, I had read your poset a little while back and missed the significance of that until after I focused on the so I think I am using v2 signatures. “ and did some checking myself to see how you would display that. Not sure, otherwise, the Mavericks section also has… • It records substantially all files by default. There are no default holes (omit rules). • It records nested code (frameworks, dylibs, helper tools and apps, plug-ins, etc.) by recording their code signature for verification. • It records symbolic links. Version 1 resource envelopes ignore symlinks. There was some mention awhile ago I think that a jli(?) lib used a symbolic link or something like that? That might of been mentioned on the old Apple java-dev list. Would cause a problem now. You could ‘ls’ all the files in your embedded jre checking for any sum version=2 rules=12 files=7 Since it is now “all files” you could verify the file count in your bundle is actually 7? Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter
