New issues in notarization of jpackage-created Mac applications

[James Elliott]

As I noted earlier on this mailing list, until this past week I had been successfully notarizing Mac disk images containing an application by ignoring the code-signing features of jpackage (which are missing elements required for notarization; one of those is already recorded in bug JDK-8238184, https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8238184 <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8238184> but since that was filed, Apple has further tightened the requirements and it is also necessary to enable the hardened runtime via `—options runtime` and to supply an entitlements file with several important entitlements).

So, what I had been doing was creating my disk image using the early access jpackage, and a runtime created via jlink from an Amazon Corretto 11 LTS OpenJDK, with no signing, and then running `codesign —force —deep` with the necessary timestamp, runtime, and entitlements arguments and file.

That stopped working at the end of the week, because Apple started to complain that the individual binaries and native libraries of the runtime itself were not signed. Since there were many dozens of them, I despaired about what to do, and opened a support ticket with Apple (as yet no response has been forthcoming).

But in further experimentation today, I tried downloading this weeks’s release candidate of OpenJDK 14, and noticed that the binaries and native libraries within that are all properly signed and notarized by Oracle. Excellent! So I changed approaches.

I used the release candidate of OpenJDK 14 for both the jlink step to produce my tailored runtime, and then used that with jpackage to create an application image. I then code signed the application image (without attempting to use —deep) to add the necessary timestamp, hardened runtime, and entitlements. I then put that into a disk image and submitted it to Apple for notarization.

It *almost* worked, but I received the following error report from Apple:

{
  "logFormatVersion": 1,
  "jobId": "c8195a4f-3e5b-492b-be27-dc22f20efb42",
  "status": "Invalid",
  "statusSummary": "Archive contains critical validation errors",
  "statusCode": 4000,
  "archiveFilename": "Beat_Link_Trigger.dmg",
  "uploadDate": "2020-02-08T23:04:13Z",
  "sha256": "3d0c25a6e6563f2c69201c74ea48c182b1df590838436bc84a57f4e9b25ea934",
  "ticketContents": null,
  "issues": [
    {
      "severity": "error",
      "code": null,
      "path": "Beat_Link_Trigger.dmg/Beat Link Trigger.app/Contents/runtime/Contents/MacOS/libjli.dylib",
      "message": "The signature of the binary is invalid.",
      "docUrl": null,
      "architecture": "x86_64"
    }
  ]
}
Looking into the application image package contents, I discovered that for some reason, there were two copies of libjli.dylib present. In addition to the expected one in:
  My.app/Contents/runtime/Contents/Home/lib/libjli.dylib
there was an additional copy (and nothing else) in:
  My.app/Contents/runtime/Contents/MacOS/libjli.dylib

That second one was the one that was causing the notarization to fail.

I updated my build script to remove that extra folder, Contents/runtime/Contents/MacOS/, from the application image before code signing, building the disk image, and submitting it for notarization, and I was back in business creating successfully notarized Java applications. Note that the application appears to work just fine without the redundant, problematic copy of libjli.dylib inside it.

You can find the build script that does all this here:
https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scripts/build_dmg.zsh <https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scripts/build_dmg.zsh>

It is driven by this GitHub Actions workflow:
https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/workflows/uberjar.yml <https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/workflows/uberjar.yml>

Please let me know if there is any more information I could provide, or if you think I should open this as a bug in itself.

Thanks,

  -James