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: What do we need to change to sign java appbundle since updating from 10.9.4 to 10.9.5
On the javapacakger (javafxpackager) side of the house we dodge this by not using the symlinked JLI. The JDK as it is installed installs a symlink to the libjli.dylib in ...app/Contents/MacOS is actually a symlink. I don't know if you copy it if it will still work, it may want to live in ...app/Contents/Home/jre/lib/jli/libjli.dylib. This is referenced in the default info.plist The way we dodge this for the javapackager is we create our own launch native that opens up the libjli from the location deep in the JRE. And we don't ship the symlink. I can confirm that javapackager 8u20 signs and launchers with 10.9.5, but I haven't tried to submit it to the app store since the signing requirements changes. So I don't know how you launch, but the info.plist cannot refer to the symlinked libjli.dylib if it is symlinked, and it may not even be allowed to exist as a symlink in ...app/Contents/MacOS. So if you can remove the symlink before signing that may help. On Sep 18, 2014, at 10:19 AM, Paul Taylor paul_t...@fastmail.fm wrote: Can somebody help me with this please I just updated from OSX 10.9.4 to 10.9.5, and it looks like I have to change how I sign Java application after updating because Im now getting this output after signing with export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate /usr/bin/codesign --sign Developer ID Application: P Taylor --force --deep --verbose /Applications/SongKong.app Im getting: /Applications/SongKong.app: the main executable or Info.plist must be a regular file (no symlinks, etc.) In subcomponent: /Applications/SongKong.app/Contents/PlugIns/jdk1.8.0_20.jdk and verification with /usr/bin/codesign --verify --deep --verbose /Applications/SongKong.app gives me /Applications/SongKong.app: code object is not signed at all In architecture: x86_64 What do I have to change to fix this ? Paul
