See https://bugs.openjdk.java.net/browse/JDK-8235687
I noticed this was recently discussed on the OpenJDK email list. Scott > On Feb 8, 2020, at 11:06 PM, James Elliott <ja...@deepsymmetry.org> wrote: > > 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
