Signing bundled JRE

Steve Hannah steve at weblite.ca
Tue Aug 21 16:31:56 PDT 2012


Thanks for all the response.    As it turns out I think I may be able to
get by without codesigning the embedded JRE.  The error that comes up seems
to have been more of a guideline.

Thanks particularly to you, Marco for your great instructions on the
process.  I did find, though, that if I first sign the internal dylibs and
jar files before I sign the bundle, then I will end up with an invalid
application:

codesign --verbose --verify /Applications/myapp.app
/Applications/myapp.app: a sealed resource is missing or invalid
In architecture: i386

I presume this is because the signing process modifies the internal
libraries of the bundle after the bundle has already been signed.

My signing script ended up something like the following:

# First sign all of the jar files and dylib files
find "$APP_PATH/Contents" -type f \( -name "*.jar" -or -name "*.dylib" \)
-exec codesign --verbose=4 -f -s "$CERT"  --entitlements
"$ENTITLEMENTS_PATH" {} \;

# Verify that they were all signed properly
find "$APP_PATH/Contents" -type f \( -name "*.jar" -or -name "*.dylib" \)
-exec codesign --verbose=4 --verify {} \;

# Re-sign all of the jar files and dylibs inside of the bundled JDK so that
they match the bundle id (net.java.openjdk.jdk)
find "$APP_PATH/Contents/Plugins/1.7.0u6.jdk/Contents" -type f \( -name
"*.jar" -or -name "*.dylib" \) -exec codesign --verbose=4 -i
"net.java.openjdk.jdk" -f -s "$CERT"  --entitlements "$ENTITLEMENTS_PATH"{} \;

# Verify that all of the JDK libs were signed properly
find "$APP_PATH/Contents/Plugins/1.7.0u6.jdk/Contents" -type f \( -name
"*.jar" -or -name "*.dylib" \) -exec codesign --verbose=4 --verify {} \;

# REMOVED:  Signing the JDK bundle just breaks everything...
#codesign --verbose=4 -f -s "$CERT" --entitlements "$ENTITLEMENTS_PATH"
"$APP_PATH/Contents/Plugins/1.7.0u6.jdk"

# Finally we sign the whole application bundle
codesign --verbose=4 -f -s "$CERT" --entitlements "$ENTITLEMENTS_PATH"
"$APP_PATH"

This at least got me past the evil "Invalid Binary" errors upon uploading,
even though it still warns me that the embedded application bundle Java 7
SE is not signed.

Thanks again

Steve


On Tue, Aug 21, 2012 at 4:00 PM, Marco Dinacci <marco.dinacci at gmail.com>wrote:

> Hi Steve,
>
> > I just tried submitting my Java app to the app store last night and
> > received an error message saying that my nested app bundle Java SE 7 is
> not
> > signed.  If, however, I sign the nested bundle, my app will no longer
> open.
> >  I get a Console log message saying that the application exited with
> Code:
> > 2.
>
> I encountered this problem too, I forgot to add it to my guide....
> If you sign all the files in the bundle it won't work as codesign
> doesn't follow the symlinks.
>
> First sign your bundle:
> codesign --verbose -f -s "$SIGNATURE_APP" --entitlements $ENTITLEMENTS
> $YOUR_APP.app
>
> Then sign all the libraries:
> find $YOUR_APP/Contents/ -type f \( -name "*.jar" -or -name "*.dylib"
> \) -exec codesign --verbose -f -s "$SIGNATURE_APP" --entitlements
> $ENTITLEMENTS {} \;
>
> Finally you can create the package:
> productbuild --component YOUR_APP.app /Applications --sign
> "$SIGNATURE_INST" YOUR_APP.pkg
>
> You can test if the package work with this command:
>
> sudo installer -store -pkg $YOUR_APP.pkg -target /
>
> You can also verify all libraries have been signed
> find YOUR_APP/Contents/ -type f \( -name "*.jar" -or -name "*.dylib"
> \) -exec codesign --verbose --verify {} \;
>
>
> Best,
> Marco
>



-- 
Steve Hannah
Web Lite Solutions Corp.


More information about the macosx-port-dev mailing list