Hardened runtime for Java and Mojave

Question

I currently distribute a Java application, packaged and signed using pkgbuild on macOS.

Recently, Apple warns developers:

"In an upcoming release of macOS, Gatekeeper will require Developer ID–signed software to be notarized by Apple."

Upon reading the notarizing docs, apple warns developers:

"You must enable hardened runtime for your app to be notarized by Apple."

Which goes into some details about how to toggle these settings on within Xcode. But what about apps not developed with Xcode? Xamarin/Mono have some back and forth about how they're tackling this but the commits so far seem to focus on Mojave detection and C/C++. What about Java apps or apps that don't distribute any C/C++/Objective-C compiled code? How does a project get "notarized" so that it doesn't get blocked by a future macOS update?

Possibly related: How to codesign and enable the hardened runtime for a 3rd-party CLI on Xcode?

Answer 1

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 using xcrun 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 the Keychain 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 use codesign 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 john@domain.com -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 john@domain.com

• 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

Answer 2

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/>

Answer 3

Here is a simple shell script that will codesign the .so, .dylib and .jnilib within a jar file

usage: codesign_jar_script.sh filename.jar

jar tf $1 | grep '\.so\|\.dylib\|\.jnilib'  > filelist.txt

IDENTITY="your_signing_identity"

echo $IDENTITY

while read f
do
    jar xf $1 $f
    codesign --force -s "$IDENTITY" -v $f
    jar uf $1 $f
    rm -rf $f
done < filelist.txt