For some context, I’m using the jpackage utility to try to create a signed DMG file to deliver to my users. The reason I need to sign this DMG is because I would like to notarize the software. By the way, I’m not sure if notarization is possible (yet) using jpackage but I’m trying it anyway.
However, I am having trouble using jpackage’s inbuilt code signing options, which is a prerequisite to successful notarization.
I am running jpackage using the options --mac-sign --mac-package-signing-prefix CardrDebate --mac-signing-key-user-name "Developer ID Application: ********** (*******)" (I’ve redacted the actual developer ID since this is public on StackOverflow).
After creating the jpackage app image, I tested whether the generated code was actually signed by navigating to several of the generated .dylib files and trying codesign -vvv {filename}.dylib, and codesign said that the objectwas not signed at all (NOT that it was incorrectly signed, but that it just wasn’t signed at all).
Thus, I believe that my problem is from my (potentially) incorrect usage of jpackage’s signing options on macOS. How should I be using these?
Advertisement
Answer
I’ll go ahead and answer my own question because I ended up figuring out how to sign my application and get it successfully notarized from the Apple notarization service (my product is http://cardr.x10.bz).
Use jpackage’s app-image option to generate an unsigned app bundle.
Use an automated bash script to codesign all dylib and executable files inside of the app bundle, using
codesign -vvv --options runtime --deep --force --sign "Developer ID Application: ********" <filename>.This is a multi-step procedure, so I’ll just split it up into A/B/C.
3A) Find all jar files within the MyApp.app/Contents/mods/ that contain embedded .dylib files, and extract those files to a specific folder (or write a small program to do this for you). For me, my app relied on JavaFX, so many of the JavaFX libraries contained .dylib files within the jar files. However, if you’re just using the default Java libraries, you should be able to skip to step 4, since the default Java libraries don’t contain .dylib files. The reason we need to do this step is becuase Apple’s notarization service checks these embedded .dylib files for codesigning as well.
3B) Use an automated bash script to codesign all dylib files that you just extracted, using codesign -vvv --options runtime --deep --force --sign "Developer ID Application: ********" <filename>.
3C) Add each of signed .dylib files back into their respective jar files to replace the original unsigned embedded .dylib files. Here’s a command that may come in handy: jar uf <path to jar file> <path to dylib file>. Keep note that the second path specified, the path to the dylib file, should also be the dylib’s relative location within the archive. Take a look here for more details – https://docs.oracle.com/javase/tutorial/deployment/jar/update.html.
Now that you’ve signed each of the executable files and dylib files within the .app, it’s time to sign the .app itself. Run
codesign -vvv --force --sign "Developer ID Application: ********" MyApp.app.Now that you have signed the .app, you need to run jpackage on the app bundle to create either a DMG or a PKG out of it. Feel free to use the jpackage mac signing features, which will sign the outer DMG/PKG. Take note that the property
--mac-signing-key-user-name "My Developer Account Name (*******)"should NOT include the “Developer ID Application/Installer” part of the certificate.Finally, you have created a signed PKG/DMG ready for notarization. Use
xcrun altool --notarize-app --username <apple-id> --password <app-specific-password> <MyApp.dmg or MyApp.pkg>. Wait for notarization to complete and make sure it is approved.If notarization succeeded (it should), you can staple your app’s ticket to the PKG installer using
xcrun stapler staple MyApp.pkg.
Hope this helps!