MacOS hardened runtime support

[tkie]

I would like to bundle the AdoptOpenJDK into a MacOS application. To use Apple's notary service all executables in my app have to be codesigned with hardened runtime support.

The ApoptOpenJDK executables are codesigned already, but unfortunately without hardened runtime support.

I can re-sign them myself like this:

codesign --verbose --options runtime --force --sign "Developer ID Application: SecSign Technologies Inc." bin/java

but apparently this damages the executables. For example "java" is not able to print its version any more:

java --version
Error occurred during initialization of VM
Could not reserve enough space in CodeHeap 'non-nmethods' (2496K)

Would the ApoptOpenJDK team be able to enable the hardened runtime ("--options runtime") during the codesigning in the build process of the AdoptOpenJDK? This would be great.

Thank you in advance for any comments on this issue.

Kind regards Tilo

[gdams]

when I try and add this flag I get the following error: error: invalid or inappropriate API flag(s) specified

[karianna]

@tkie Do you have any further insights here?

[gdams]

looking at https://help.apple.com/xcode/mac/current/#/dev033e997ca it suggests that we may need to codesign on macOS 10.13 or above, let me have a play here.

[tkie]

I use XCode Version 10.3 (10G8) on MacOS 10.14.6. I don't know which is the minimum XCode version to support the hardened runtime, but it is a rather new feature.

[gdams]

okay so I've made a bit of progress here, I can sign enable a jdk12 build. In order to work around the error:

Error occurred during initialization of VM
Could not reserve enough space in CodeHeap 'non-nmethods' (2496K)

you need to add entitlements in the form of a plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <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.allow-dyld-environment-variables</key>
    <true/>
</dict>
</plist>

and then add --entitlements <path to entitlements.plist> as a flag when you codesign.

inspecting the executable I can now see the runtime option:

➜  Home codesign -dvvv ./bin/java
Executable=/Users/gdams/tmp/jdk-11.0.4+11/Contents/Home/bin/java
Identifier=net.java.openjdk.cmd
Format=Mach-O thin (x86_64)
CodeDirectory v=20500 size=832 flags=0x10000(runtime) hashes=17+5 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=89dde46e6d5094c92508bc3d95ecf04cbf2e5c6b
CandidateCDHash sha256=7504cd1dc13d553e9cb3d469a508900a34d3cbc7
Hash choices=sha1,sha256
CDHash=7504cd1dc13d553e9cb3d469a508900a34d3cbc7
Signature size=9037
Authority=Developer ID Application: London Jamocha Community CIC (VDX7B37674)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=30 Jul 2019 at 11:12:25
Info.plist entries=4
TeamIdentifier=VDX7B37674
Runtime Version=10.10.0
Sealed Resources=none
Internal requirements count=1 size=180

[gdams]

@tkie can you confirm that the above also works for you? If it does then I'll get that change added to the build scripts.

[gdams]

I've also managed to make this work on jdk8 by adding this to the entitlements.plist file:

<key>com.apple.security.cs.disable-library-validation</key>
<true/>

[gdams]

test jdk11 app notarization: report (successful)

test jdk12 app notarization: report (successful)

[tkie]

@gdams I'm sorry, I have never built the JDK myself. I have always downloaded binary distributions. Maybe you could make your today's JDK 11 test build for MacOS available for download somewhere? Then I could try to get a notarization from Apple for my application into which I would like bundle the JDK. So I could confirm whether your change works.

[gdams]

@tkie I've landed a fix that fixes anything on JDK11+. Please note that this change won't be noticeable until our next release (I'll discuss with the Adopt folks the possibility of a re-release so that people can consume this immediately.

On JDK8 we still have an issue:

The binary uses an SDK older than the 10.9 SDK

My suggestion would be that we investigate shipping a JDK8 build that is optimized for bundling (i.e built on a later toolchain) but this might not be a simple task as it requires a load of backports from later JDK's to the JDK8u repo.

[gdams]

@tkie I have a JDK12 build you can try here: https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk12u/job/jdk12u-mac-x64-hotspot/

JDK11 Build: https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-mac-x64-hotspot/

[tkie]

@gdams Thank you for the JDK12 build. I can confirm that my application including the JRE from OpenJDK12U-jre_x64_mac_hotspot_2019-07-31-11-04.tar.gz was notarized by Apple.

[tkie]

@gdams I have also tested with OpenJDK11U-jre_x64_mac_hotspot_2019-07-31-11-27.tar.gz. Notarization with it was also successful. From my point of view the issue is solved and it would not be necessary to investigate Java 8. Thank you for having solved this issue for Java 11 and above.

[thartwell]

We also get the "The binary uses an SDK older than the 10.9 SDK" error when we attempt to notarize our application with Java 1.8 Runtime included .

We currently need to stay with Java 1.8 so can't upgrade to a more recent Java.

Is there a date when an updated Java 1.8 runtime will be available that will pass this notarization test ?

[benjohnde]

I can also confirm that it is fixed with https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk12u/job/jdk12u-mac-x64-hotspot/.

[adamulrich]

When can we expect an openjdk 8 build that passes notarization?

[karianna]

When can we expect an OpenJDK 8 build that passes notarization?

It may be some time, currently, no OpenJDK provider has this support. The challenge is that jdk8u needs to be built on Mac Os X 10.10 whereas notarization is a 10.14 concept.

[davideby]

Hi folks, I'm not sure this is totally closed. We're bundling the latest macOS OpenJDK 11 JRE (OpenJDK11U-jre_x64_mac_hotspot_11.0.5_10.tar.gz) with our app and while the notarization process succeeds, we get a number of warnings in the JSON log that indicate it will (probably) fail in the future. For example:

{
  "severity": "warning",
  "code": null,
  "path": "XYZ.app.zip/XYZ.app/Contents/jdk-11/bin/java",
  "message": "The executable does not have the hardened runtime enabled.",
  "docUrl": null,
  "architecture": "x86_64"
},

It looks like the successful notarization others have reported may be due to Apple temporarily relaxing the notarization requirements until January 2020.

I can pass along our copy of the log if it's helpful.

[xGnoSiSx]

Did you add the entitlement for JIT capabbility? Without it notarization fails. pretty sure the JRE needs this.

https://developer.apple.com/documentation/security/hardened_runtime_entitlements

[davideby]

I tried this using the upstream example from @gdams. We're not using Xcode but the command-line tools instead. It's possible I'll need to switch but hopefully can avoid that. It may just be a matter of revamping the signing steps; things were simpler before notarization...

To be clear, notarization succeeds even without it, due to Apple's current relaxed requirements. The concern is that the warnings indicate failure in the future.

[tkie]

If anybody tells me where to find the JSON log mentioned by @davideby when using XCode, I will do another notarization of our software using XCode and check if I get such warnings too. I can only tell that the notarization is successful, but I did not check a log file for warnings yet.

[davideby]

I'm working from this document. See the section "Check the Status of Your Request" in particular.

[tkie]

@gdams It seems the hardenend runtime support has disappeared again? If I use jdk-11.0.4+11.4 then the notarization works. But with jdk-11.0.5+10 I get the error that hardened runtime support is not enabled.

[vbanchenko]

It looks like you sign executables without hardened runtime option. Try to add --option runtime to your codesign command.

On Tue, Nov 5, 2019, 07:56 David Eby notifications@github.com wrote:

Hi folks, I'm not sure this is totally closed. We're bundling the latest macOS OpenJDK 11 JRE (OpenJDK11U-jre_x64_mac_hotspot_11.0.5_10.tar.gz) with our app and while the notarization process succeeds, we get a number of warnings in the JSON log that indicate it will (probably) fail in the future. For example:

{ "severity": "warning", "code": null, "path": "XYZ.app.zip/XYZ.app/Contents/jdk-11/bin/java", "message": "The executable does not have the hardened runtime enabled.", "docUrl": null, "architecture": "x86_64" },

It looks like the successful notarization others have reported may be due to Apple temporarily relaxing the notarization requirements https://developer.apple.com/news/?id=09032019a until January 2020.

I can pass along our copy of the log if it's helpful.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/AdoptOpenJDK/openjdk-build/issues/1130?email_source=notifications&email_token=ALFWETDWY6UNPTKTOAOHGFLQSEDKHA5CNFSM4H3I6DJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDBV2EQ#issuecomment-549674258, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALFWETGV56Q5HXDOMCPKBKTQSEDKHANCNFSM4H3I6DJQ .

[marco-boeck]

Apple has released an update: https://developer.apple.com/news/?id=12232019a So do I understand it correctly that using JDK8 on OS X 10.15 will just start failing completely starting Feb 03 (in 4 weeks)? That'd be pretty bad..

[adamulrich]

Apple has released an update: https://developer.apple.com/news/?id=12232019a So do I understand it correctly that using JDK8 on OS X 10.15 will just start failing completely starting Feb 03 (in 4 weeks)? That'd be pretty bad..

No, that is not what will happen. It is bad, but things that are working now will continue to work. To submit an app for notarization, it has to meet a bunch of requirements, one of them is code signing, another is runtime hardening. In order for your app that is downloaded from the internet to be installed on Catalina (10.15) , it will have to get past the gatekeeper check that it is properly notarized. That happens right now on Catalina.

What happens on Feb 03 is that you can't get your app notarized by Apple if it doesn't make the bar with regards to code signing and runtime hardening.

Apple has been in a grace period right now, so that you can submit ANYTHING, and they will notarize it, even if it doesn't make the requirements. After Feb 3, you won't be able to get an app notarized, so you won't be able to distribute a new app without it passing. Of course, In July Apple said that it would be Sepember. In September they said January, and in December they have now said Feb. So they are recognizing that things aren't right and they are going to hurt alot of people by doing so.

And their are workarounds. If a customer has admin access, they can allow anything that is not notarized to be installed anyway by going to the control panel and authorizing the app.

[adamulrich]

for those struggling with runtime hardening, add all six plist entitlements that are available, and make sure that your java runtime, whichever version you are using, is in a folder that will get codesigned when you use the -deep option (which is in MacOS, or Frameworks). If you have put your JRE in plugins, it assumes that it was codesigned by the 3rd party, and will not codesign or harden that location. Any other locations, outside of MacOS and Frameworks, codesigning ignores.

[marco-boeck]

Even if signing it ourselves may or may not work, I do not see how anyone on the outside can fix the following type of notarization warnings (which will become a errors and block all future notarizations Feb 3):

"severity": "warning",
"code": null,
"path": "mydmg.dmg/MyApp.app/Contents/Helpers/jre_1.8.0_XX.jre/Contents/Home/lib/libzip.dylib",
"message": "The binary uses an SDK older than the 10.9 SDK.",
"docUrl": null,
"architecture": "x86_64"

According to https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/resolving_common_notarization_issues, this is expected and the binaries need to be created with a newer version in the first place.

We can't just stop releasing updates to our software for OS X 10.15+ starting Feb 3, but currently it looks like that's exactly what will happen.. And telling corporate environments they should just disable some security mechanism for us is often impossible and never an acceptable path..

[parched]

We can't just stop releasing updates to our software for OS X 10.15+

FWIW our solution was to build it ourselves with a newer SDK via https://github.com/stooke/jdk8u-xcode10

[sithmein]

It seems since yesterday all those notarization warnings have finally turned into errors. Which means we cannot notarize our Java-based applications any more :(

[MoxxiManagarm]

Hi folks. Just wanna mention my issue here again since my linked issue was closed referencing to this one. I still hope someone has a great hint how to fix.

Our application logic is contained within a jar file. This jar file is later bundled into an application package with the packagesbuild command (http://s.sudre.free.fr/Software/Packages/about.html). This bundle also contains the AdoptOpenJDK JRE 11.0.4. This means we ship this version with our application to make sure our application is always started with the required.

We then sign the code like this

# signing the main application
    codesign --deep --force --timestamp --strict --entitlements "${ENTITLEMENTS_DIR}" \
      --options runtime --sign "${CERT_DEV_ID_APPLICATION}" "${DIR_TO_OUR_APP_JAR}"

    # signing the java binaries
    find ${DIR_TO_JRE} -type f -exec \
      codesign --deep --force --timestamp --strict --entitlements "${ENTITLEMENTS_DIR}" \
      --options runtime --sign "${CERT_DEV_ID_APPLICATION}" '{}' \;

Of course all 6 entitlements are there and are also be visible after having the application installed.

Everything works fine until hardened runtime is enabled. Notarization passes, but the application can't be launched with the shipped java version. It says

Error occurred during initialization of VM Could not reserve enough space in CodeHeap 'non-nmethods' (2496K)

Starting the application with a preinstalled java version seems to work fine.

[abauman-7signal]

It seems since yesterday all those notarization warnings have finally turned into errors. Which means we cannot notarize our Java-based applications any more :(

I experienced the same issue yesterday. Today, it's fine. Yesterday, Apple reported the Java libraries as not signed and in error. Today, they are reported as not signed but in warning. Bottom line, Apple notarized my package.

[Conky5]

I experienced the same issue yesterday. Today, it's fine.

I saw this as well, perhaps it was Apple kicking the tires on the stricter rules that are planned to be enforced on February 3rd.

When attempting notarization with jdk-13.0.1+9 files in .jmod files are being detected as not being signed by Apple's notarization service, for example:

    {
      "severity": "warning",
      "code": null,
      "path": "[...]/Contents/Home/jmods/jdk.jartool.jmod/bin/jarsigner",
      "message": "The binary is not signed.",
      "docUrl": null,
      "architecture": "x86_64"
    },

I see jmod signing was removed August 21st in https://github.com/AdoptOpenJDK/openjdk-build/commit/5cd5306b4e97437aa2129dffd7e83e2f7cfd9255#diff-9a6d9f1628b9075aa2e1b4c33e4b9cc8 and is still commented out. The mentioned ticket https://github.com/AdoptOpenJDK/TSC/issues/107 has been closed, are there plans to bring this back?

[MoxxiManagarm]

Error occurred during initialization of VM Could not reserve enough space in CodeHeap 'non-nmethods' (2496K)

After having another look on this it seems the issue was in our script. It was historically grown, that we additionally sign the JRE. I now simply removed the find-sign part for JRE and it seems so work.

[mstrelex]

As @abauman-7signal mentioned indeed all errors are again warnings now, perhaps until February 3rd Any ideas how to notarize OpenJDK 13 and make it actually work afterwards?

[vincent-paing]

Any good way to fix this now? On macOS 10.15.2 and trying to use openjdk8

[aahlenst]

I try to summarize the current state. The summary might contain errors, because I'm not an expert in this area. @gdams is who's leading the effort to get AdoptOpenJDK notarized and enabling hardened runtime support, but he's busy getting it done. So take it with a grain of salt…

Work on JDK 11 with HotSpot has completed with JDK 11 with OpenJ9 following soon. Bundling the JDK is supposed to work without problems. The result of this work is expected to be included in the next quarterly CPU (April 2020). Whether there are going to be rebuilds of 11.0.6 that would be available sooner with complete notarization and hardened runtime support has not been decided yet. Existing binaries are already notarized and should continue running beyond February 3rd without problems:

$ codesign -dvv ~/Downloads/jdk-11.0.6+10/Contents/Home/bin/java  
Executable=/Users/andreas/Downloads/jdk-11.0.6+10/Contents/Home/bin/java
Identifier=net.java.openjdk.cmd
Format=Mach-O thin (x86_64)
CodeDirectory v=20200 size=276 flags=0x0(none) hashes=4+2 location=embedded
Signature size=9038
Authority=Developer ID Application: London Jamocha Community CIC (VDX7B37674)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=15 Jan 2020 at 13:14:22
Info.plist entries=4
TeamIdentifier=VDX7B37674
Sealed Resources=none
Internal requirements count=1 size=180

JDK 8 is still work in progress an there's no ETA. The main problem here is that JDK 8 only supports building with older Xcodes which in turn do not support notarization and hardened runtime. An effort to use newer Xcode versions is underway but the resulting binaries do not pass the test suite yet. @gdams is looking into it together with Apple. The existing executables are notarized and should continue running beyond Feburary 3rd:

$ codesign -dvv ~/Downloads/jdk8u242-b08/Contents/Home/bin/java
Executable=/Users/andreas/Downloads/jdk8u242-b08/Contents/Home/bin/java
Identifier=net.java.openjdk.cmd
Format=Mach-O thin (x86_64)
CodeDirectory v=20200 size=884 flags=0x0(none) hashes=23+2 location=embedded
Library validation warning=OS X SDK version before 10.9 does not support Library Validation
Signature size=9038
Authority=Developer ID Application: London Jamocha Community CIC (VDX7B37674)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=19 Jan 2020 at 16:38:24
Info.plist entries=4
TeamIdentifier=VDX7B37674
Sealed Resources=none
Internal requirements count=1 size=180

JDK 14 which is going to be released in March should have the same capabilities as JDK 11. Nightly builds of JDK 14 with notarization and hardened runtime support should be available soon. At least https://github.com/AdoptOpenJDK/openjdk-build/pull/1517 is required for this.

All other JDKs (9, 10, 12, 13) have reached their end of life and are therefore out of scope.

[mdgood]

Thank you for this update and your work in resolving this.

Please do make a rebuild of 11.0.6 available as soon as feasible. As it stands, I believe that developers like us who ship applications with an embedded Java runtime would not be able to ship a new build that works on Catalina after February 3 until 11.0.7 is released two months from now. (Unless you managed to grab 11.0.4+11.2 before it was removed, which we did.)

I would be happy to test it with our application build and notarization system before a more general release if that helps.

[gdams]

I would be happy to test it with our application build and notarization system before a more general release if that helps.

@mdgood you can already grab one of our nightly builds of JDK11 which has the newer updated notarization updates. Please see https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-mac-x64-hotspot.

I'd be interested to see how you get on? Let me know!

[mdgood]

@gdams Thanks for the pointer - that's great news! I will grab this and report back on our results.

[jasontedor]

JDK 14 which is going to be released in March should have the same capabilities as JDK 11. Nightly builds of JDK 14 with notarization and hardened runtime support should be available soon. At least #1517 is required for this.

All other JDKs (9, 10, 12, 13) have reached their end of life and are therefore out of scope.

Note that JDK 13 is not at end of life. It will only reach end of life when JDK 14 is released in March. Please reconsider and issue another build of JDK 13 that is notarized, so that it’s possible to have a notarized build of the latest JDK.

[mdgood]

@gadams The January 30 nightly build of 11.0.7 is working fine for us. Our application build notarized without warnings, and installs and works fine on Catalina. I will try building and notarizing our application again next week after the new restrictions kick in just to double-check.

[mdgood]

Building and notarizing worked fine yesterday as well.

[wjg57]

As of 2020-02-06 06:01:30 +0000 I'm getting notarization errors like:

severity | "error" path | "..../Contents/Plugins/Java.Runtime/Contents/Home/jre/bin/java" message | "The binary uses an SDK older than the 10.9 SDK." architecture | "x86_64"

so I'd assume that you will see the same issue in the near future.

[addsomebass]

Is there any progress or timeline for a Java 8 JRE built against 10.9 or later? We still need to bundle with Java 8 due to RMI changes.

Any info would be appreciated. If there are still significant hurdles, we can look into building it ourselves with this repo mentioned previously: https://github.com/stooke/jdk8u-xcode10

However, if there will be a Java 8 JRE available within the next few days I would much prefer to wait for that.

[aahlenst]

@addsomebass There is nothing imminent. And if I remember correctly, one of our team members played around with the patches you are linking to and the resulting binaries did not pass the test suite. So you‘d bundle a JDK with known defects.

[gdams]

@addsomebass I've been working with Apple to resolve the test failures mentioned by @aahlenst. I will reiterate that the patches in https://github.com/stooke/jdk8u-xcode10 are not production ready and have test failures.

My current goal is to have a notarized jdk8 binary ready by the end of the month.

[addsomebass]

Thank you for the update @gdams, I really appreciate your work on this.

[gravelld]

Thanks for everyone's work on this - although I still have a problem.

I'm using jpackage from the latest EA of JDK14 to build a .app file. The file has this structure:

MyApp.app/
  Contents/
    MacOS/ <- the launcher
    Resources/
    PkgInfo
    Info.plist
    app/ <- the libs for the app
    runtime/ <- contents of jdk-11.0.7+2-jre

The problem is, I can either:

• Build a notarized app, but it won't run, or
• Build a runnable app, but it won't notarize

To put one thing aside - signing apps for Mac in jpackage is currently broken so I can't use that. It was working when the runtime wasn't signed, but now it's clear I need to do the signing myself.

It looks to me that I'm misunderstanding something about how the runtime (the JRE) is incorporated, and the requirements for its signing.

First I sign all files not in the runtime and that aren't launchers:

% find my-app.app -type f -not -path "*/Contents/runtime/*" \
  -not -path "*/Contents/MacOS/my-app" \
  -not -path "*libapplauncher.dylib" \
  -exec codesign -v -s "my key" --prefix com.myapp. --keychain /Users/myuser/Library/Keychains/codesigning.keychain {} \;

I figured that if the runtime is already signed it won't need re-signing.

At this point, my app runs. However:

% spctl -a -t exec -vv my-app.app
my-app.app: code has no resources but signature indicates they must be present

I'm not really sure what this means - only thing I can find online is that it might mean the app is corrupt. That's not really much info to be going on.

So I try:

% spctl -a -t exec -vv my-app.app/Contents/runtime 
my-app.app/Contents/runtime: code has no resources but signature indicates they must be present

I'm not sure if that means it's the runtime that is the source of the issue. If I run the same check against the original JRE source (before it was packaged by jpackage) I get the same result.

% codesign -vvv --deep --strict /path/to/jdk-11.0.7+2-jre 
/path/to/jdk-11.0.7+2-jre: code has no resources but signature indicates they must be present
% codesign -dv --deep --strict /path/to/osx/jdk-11.0.7+2-jre 
Executable=/path/to/jdk-11.0.7+2-jre/Contents/MacOS/libjli.dylib
Identifier=libjli
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20500 size=786 flags=0x10000(runtime) hashes=16+5 location=embedded
Signature size=9038
Timestamp=8 Feb 2020 at 19:20:05
Info.plist=not bound
TeamIdentifier=VDX7B37674
Runtime Version=10.14.0
Sealed Resources=none
Internal requirements count=1 size=168

So now I sign the app:

codesign -f -s "my key" --options=runtime --prefix com.myapp. --keychain /Users/myuser/Library/Keychains/codesigning.keychain my-app.app

I have to use --options=runtime otherwise I get an error The executable does not have the hardened runtime enabled.

Check again:

% spctl -a -t exec -vv my-app.app
bliss-5.app: accepted
source=Developer ID
origin=Developer ID Application: D Gravell (366TU22RYQ)

Hooray! But if I do the same check on the runtime folder with the JRE in it, I still get the same message.

This gives the notarization result:

      "path": "my-app.dmg/my-app.app/Contents/runtime/Contents/MacOS/libjli.dylib",
      "message": "The signature of the binary is invalid.",

Also, the app no longer runs:

% my-app.app/Contents/MacOS/my-app
2020-02-12 14:39:08.685 bliss[2909:61940] /private/tmp/my-app.app/Contents/MacOS/libapplauncher.dylib not found.

So then I realised this file wasn't signed (so why is spctl allowing this???) and so I sign it:

% codesign -f -s "My key" --options=runtime --prefix com.myapp. -vv --keychain /Users/gravelld/Library/Keychains/codesigning.keychain my-app.app/Contents/MacOS/libapplauncher.dylib
% codesign -vvv --deep --strict my-app/Contents/MacOS/libapplauncher.dylib
my-app.app/Contents/MacOS/libapplauncher.dylib: valid on disk
my-app.app/Contents/MacOS/libapplauncher.dylib: satisfies its Designated Requirement

I then have to re-sign the app, otherwise it gives an error about files being modified.

But it still won't run, this time due to an issue with the JRE:

% my-app.app/Contents/MacOS/my-app
2020-02-12 14:45:51.846 my-app[2919:63060] Failed to find library.:/private/tmp/my-app.app/Contents/runtime/Contents/Home/lib/jli/libjli.dylib
2020-02-12 14:45:51.847 my-app[2919:63060] my-app:Failed to locate JLI_Launch
2020-02-12 14:45:51.847 my-app[2919:63060] my-app:Failed to launch JVM

Now if I sign the runtime, to also address the notarization issue:

% codesign -f -s "my key" --options=runtime --prefix com.myapp. -v --keychain /Users/gravelld/Library/Keychains/codesigning.keychain  my-app.app/Contents/runtime/Contents/Home/lib/jli/libjli.dylib
my-app.app/Contents/runtime/: replacing existing signature
my-app.app/Contents/runtime/: signed bundle with Mach-O thin (x86_64) [com.oracle.java.com.myapp]

And re-sign the app again, because the app has changed. I now get this beauty when running:

% my-app.app/Contents/MacOS/my-app
Error: dl failure on line 542
Error: failed /private/tmp/my-app.app/Contents/runtime/Contents/Home//lib/server/libjvm.dylib, because dlopen(/private/tmp/my-app.app/Contents/runtime/Contents/Home//lib/server/libjvm.dylib, 10): no suitable image found.  Did find:
    /private/tmp/my-app.app/Contents/runtime/Contents/Home//lib/server/libjvm.dylib: code signature in (/private/tmp/my-app.app/Contents/runtime/Contents/Home//lib/server/libjvm.dylib) not valid for use in process using Library Validation: mapping process and mapped file (non-platform) have different Team IDs
2020-02-12 14:53:03.153 my-app[2942:64467] my-app:Failed to launch JVM

However, this still doesn't notarize:

      "path": "my-app.dmg/my-app.app/Contents/runtime/Contents/MacOS/libjli.dylib",
      "message": "The signature of the binary is invalid.",

Sure enough:

% codesign -vvv --deep --strict my-app.app/Contents/runtime/Contents/MacOS/libjli.dylib 
my-app.app/Contents/runtime/Contents/MacOS/libjli.dylib: a sealed resource is missing or invalid
file modified: /private/tmp/my-app.app/Contents/runtime/Contents/Home/lib/jli/libjli.dylib

Ah - I remember - I signed runtime/Contents/Home/lib/jli/libjli.dylib so I need to sign the runtime bundle again, and then the wrapping app bundle.

So my questions are:

• Am I supposed to re-sign the runtime?
• Am I using the correct runtime?
• Could anyone share their successful app structures?

[dg76]

Hi!

I have managed to get it running with JDK 14, jpackage and by signing all dylibs and jars myself. Did you set these lines in your entitlements file?

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