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
