Hardened runtime for Java and Mojave
In addition to tresf's answer above, if your app is sandboxed (and possibly even if not) then the hardened runtime will fail when the JVM is loaded. To work around that you'll need to add some keys to your entitlements when signing. The necessary entitlement entries are below, copied from TAO ZHOU's solution here: https://github.com/TheInfiniteKind/appbundler/issues/39
<key>com.apple.security.cs.allow-jit</key>
<true/>
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
<key>com.apple.security.cs.disable-executable-page-protection</key>
<true/>
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
<key>com.apple.security.cs.allow-dyld-environment-variables</key>
<true/>
I'm answering this question in regards to a Java project that requires notarization. With slight modifications, the answer should work for other types of projects (python, powershell, node) as well.
Note: At the time of posting this, Apple's notarization command allowed the below procedure to work however as notarization and security becomes more common and more strictly enforced it is inevitable that Apple will change and improve hardening requirements and procedures. Please edit, comment or re-answer as needed.
Code Signing
- For a vanilla Java app (
.pkg
or.app
containing scripts, jars), the notarization should pass. During notarization, Apple will extract the.jar
and look for native libraries. If it finds any that aren't signed, it'll be rejected. If it doesn't, you're OK. Instructions for notarization usingxcrun
are further below. For a Java app which contains native calls (e.g. JNI) to bundled libraries (
.dylib
,.jnilib
) each bundled library must be signed using an "Application" (e.g.developerID_application.cer
) certificate.- Certificates, Identifiers & Profiles, (Click "iOS, tvOS, watchOS" dropdown) macOS, Developer ID Application. (may also say "with Kext").
- If you don't have this certificate, you'll need to request one using a CSR. In my case, I originally only had a certificate for packaging installers (not codesigning). This process can get tricky especially if you use the same private key for two certificates. Use
openssl
via command line (instead of theKeychain Access
) if you get stuck. Once you obtain the certificate, signing each native library
.dylib|.jnilib|.so|bin
gets tricky. The general idea is to usecodesign
command against the native library so that it is signed as you, the developer. The syntax is:xargs codesign -s "P6DMU6694X" -v dependency.dylib
... where
P6DMU6694X
is either the unique developer ID or the exact certificate Common Name (either will work).For a
.jar
file, this can be particularly cumbersome as each package needs to be extracted, signed and then zipped back up.
Notarization
Once the native libraries are signed the package must be sent for notarization using
xcrun
.xcrun altool --eval-app --primary-bundle-id <bundle id> -u <iTunes Connect Account> -f <file path>
Which may look something like this:
xcrun altool --eval-app --primary-bundle-id com.domain.appname -u [email protected] -f appname.pkg
You will be prompted for your Apple Developer password (NOT the password you use to login to your Mac). Edit: Since dual-factor has been mandated, you'll need to create an app-specific password for this step!
After a few minutes, the
xcrun
command will return a unique ID that can be used to determine if the notarization was approved.RequestUUID = a1b2c3d4e5-a1b2-a1b2-a1b2-a1b2c3d4e5f6
- Periodically check the status of this unique ID to see if it was approved or denied.
xcrun altool --eval-info a1b2c3d4e5-a1b2-a1b2-a1b2-a1b2c3d4e5f6 -u [email protected]
If denied, they won't directly tell you why, you have to parse the JSON response.
LogFileURL: https://osxapps-ssl.itunes.apple.com/itunes-assets/...
Read the JSON and correct the problems identified. The JSON is minified, you may want to run it through a pretty-formatter. If there are no problems, your app has been notarized and is
Ready for distribution
.{ "logFormatVersion": 1, "jobId": "a1b2c3d4e5-a1b2-a1b2-a1b2-a1b2c3d4e5f6", "status": "Accepted", "statusSummary": "Ready for distribution", "statusCode": 0, "archiveFilename": "appname.pkg", "uploadDate": "2018-10-26T05:41:12Z", "sha256": "e2350bda66...", "issues" null }
Stapling
Finally, stapling the build will ensure the package is trusted even when a network connection is not available.
(apple.com) You should also attach the ticket to your software using the stapler tool, so that future distributions include the ticket. This ensures that Gatekeeper can find the ticket even when a network connection isn’t available. To attach a ticket to your app, use the stapler tool:
xcrun stapler staple appname.pkg
Runtime
An additional solution provided by @NaderNader, if bundling the Java runtime along with a .app
, additional steps are needed to mark the distribution as a runtime
using the --option=runtime
flag, where P6DMU6694X
is your signing ID:
codesign --force --deep --options=runtime -s "P6DMU6694X" /path/to/My.app