Temurin-build: MacOS hardened runtime support

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

@tkie Do you have any further insights here?

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.

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.

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

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

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

test jdk11 app notarization: report (successful)

test jdk12 app notarization: report (successful)

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

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

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

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

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

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 ?

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

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

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.

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.

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

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.

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.

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

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

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
.

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

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.

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.

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

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

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

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.

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.

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?

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.

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?

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

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.

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.

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!

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

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.

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

Building and notarizing worked fine yesterday as well.

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.

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.

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

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

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

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?

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>

Is that the entitlements for the runtime or for the app that bundles the runtime?

I have used it for all codesign commands, e.g. for the dmg but also for all other files (dylib, jar, .app):

codesign --timestamp --entitlements src/main/deploy/package/macosx/MyApp.entitlements --options runtime --deep -vvv -f --sign "Developer ID Application: John Public (XXXXXXXXXX)" MyApp-1.0.dmg

@dg76 thanks - I'll try that. I haven't written any entitlements before now, but since Feb 3rd everything seems to have broken; maybe I was relying on default that used to be acceptable, but now aren't (obviously that applies to the hardened runtime and builds against old SDKs; which is why I am trying to adopt this build).

That appears to work, thanks! So, to document my end solution:

% security unlock-keychain -p passwordhere codesigning.keychain
% find my-app.app -type f \
  -not -path "*/Contents/runtime/*" \
  -not -path "*/Contents/MacOS/my-app" \
  -not -path "*libapplauncher.dylib" \
  -exec codesign --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain {} \;

% find my-app.app/Contents/runtime -type f \
  -not -path "*/legal/*" \
  -not -path "*/man/*" \
  -exec codesign -f --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain {} \;

% codesign -f --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain my-app.app/Contents/runtime

% codesign -f --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain my-app.app

All tests work:

% codesign -vvv --deep --strict my-app.app/Contents/runtime 
my-app.app/Contents/runtime: valid on disk
my-app.app/Contents/runtime: satisfies its Designated Requirement
% codesign -vvv --deep --strict my-app.app/                
--prepared:/private/tmp/my-app.app/Contents/MacOS/libapplauncher.dylib
--validated:/private/tmp/my-app.app/Contents/MacOS/libapplauncher.dylib
my-app.app/: valid on disk
my-app.app/: satisfies its Designated Requirement
% spctl -a -t exec -vv my-app.app          
my-app.app: accepted
source=Developer ID
origin=XXX

Does it run?

% my-app.app/Contents/MacOS/my-app 

Yes!

Does it notarize?

Status: success
Status Code: 0
Status Message: Package Approved

Hurrah!

Summary for those bundling a JRE:

• jpackage signing is broken right now, if you want to get something notarized
• You must sign your own code.
• You must re-sign the JRE. Use -f to force the signature.
• You must specify entitlements in all signing calls

Hi, can I just ask do we currently have a Mac build for Java 8 or Java 9 that allows it to be notarized according to the new rules or not ?

@ijabz if I'm understanding your question correctly, you want to bundle a jvm within an application, and then notarize that. Currently, you can't. The latest AdoptOpenJDK build is built with an older version of the Mac OS SDK and can't be repackaged and re-notarized.

If you just want to install java, the latest .pkg installers will work on OSX Catalina, and I can install and execute Java just fine. These installers have been notarized, and can install Java to your machine without issue.

gadams is working on getting a notarizable build of Java 8, and is hoping to have that done at the end of the month. I'm wishing him and everyone else luck.

if I'm understanding your question correctly, you want to bundle a jvm within an application, and then notarize that. Currently, you can't

Yes correct, okay this will require code changes on my part but does the AdoptOpenJDK Java 11 build work ?

Or if I install Oracle builds will that work, I am currently using Oracle Java 8 on MacOS and that did work until Feb 3rd, is this what you mean by a .pkg build ?

I'm just looking for a solution that I can use now, Im very unclear on what the options currently are.

@ijabz Sorry I can't speak to Java 11 or later, as I have not worked with it personally. Judging by the comments here it seems like there is a way to get a working bundle. I can only speak to working with Java 8 builds.

The mac installer packages, or .pkg files, are installers for software. Currently there are some .pkg installers available for AdoptOpenJDK builds that are notarized and will install Java correctly, like this one here:
https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u242-b08/OpenJDK8U-jdk_x64_mac_hotspot_8u242b08.pkg

I feel Im being dumb but I dont understand that on one side AdoptOpenJDk are working on a Java 8 build that is notarized but that wont be ready until end of the month, but conversely there is already an AdoptOpenJDk Java 8 installer that will already install a notarised version Java 8 ?

@ijabz I think the reason is that if something has been notarized before February 3rd 2020, it is still valid and still works on macOS Catalina. However it wouldn't be possible to notarize it again now, because the rules are more strict now. So the AdoptOpenJDK Java 8 installer was probably just notarized before February 3rd and thus can still be used.

But you cannot package it any more because since February 3rd Apple requires apps to be "hardened", which requires XCode 10. And Java 8 has not been compiled with XCode 10, so it cannot be hardened (yet).

So you can install AdoptOpenJDK Java 8 despite it is not hardened just because it was notarized before February 3rd. But now it wouldn't be possible any more to create a new version of it or to package a program with it, because it cannot be hardened and thus cannot be notarized.

From what I have read at least JDK 11.0.7 and JDK 14 seem to work fine, are compiled using XCode 10, are "hardened" and at least JDK 14 can be used to package programs.

Okay thankyou I understand better now.
One more thing when you refer to JDK 11.0.7 and JDK 14 I assume you mean AdoptOpenJDk builds, is the situation for AdoptOpenJDk builds the same as for the downloads available on the Oracle site ?

Sorry, I don't know. I have tried it only with OpenJDK (not AdoptOpenJDK but a different distribution but I guess it is the same for all OpenJDK distributions). However because it seems to require changes in JDK 8 to make it compatible with XCode 10 and, as far as I know, Oracle makes the same changes in OpenJDK and their own distribution, I would think that their JDK 8 isn't hardened either (or otherwise they would have released an OpenJDK version of Java 8 that would be hardened, too). But as I said I haven't tried it.

ok, thanks. I ask because Im not entirely sure what the advantage of using AdoptOpenJdk build is rather than just downloading from Oracle.

@ijabz Oracle JDK is only free to use for limited set of use cases (see Oracle Java SE Licensing FAQ). OpenJDK builds by Oracle are available, too, and still free to use without restrictions, but the number of supported platforms and versions is significantly lower than what we offer here at AdoptOpenJDK. As the name implies, AdoptOpenJDK are builds of OpenJDK. One of our main objectives is to upstream all the changes. Other vendors of OpenJDK (and there are many: Amazon, Azul, BellSoft, SAP, …) may have different policies.

Right, and I see they only seems to offer the MacOS build for the latest builds now, okay thanks.

@gdams, do you still expect to have a notarized jdk8 binary ready by the end of the month? Also, would that include the J9 JVM?

@gdams, do you still expect to have a notarized jdk8 binary ready by the end of the month? Also, would that include the J9 JVM?

Can you try BellSoft JDK8 distribution (https://bell-sw.com/pages/java-8u242/). I replaced AdoptOpenJDK J8 with BellSoft J8, get rid off "The binary uses an SDK older than the 10.9 SDK." and finaly got notarized.

Looks like BellSoft J8 is already notarized ready.

As I understand, BellSoft JDK is not free..

As I understand, BellSoft JDK is not free..

The GNU General Public License (GPL) with "CLASSPATH" EXCEPTION TO THE GPL
for Regular Liberica Java SE 8u242 JDK or JRE the same license as OpenJDK.

They offer commercial support if you need.

Thanks for clarification !

That appears to work, thanks! So, to document my end solution:

% security unlock-keychain -p passwordhere codesigning.keychain
% find my-app.app -type f \
  -not -path "*/Contents/runtime/*" \
  -not -path "*/Contents/MacOS/my-app" \
  -not -path "*libapplauncher.dylib" \
  -exec codesign --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain {} \;

% find my-app.app/Contents/runtime -type f \
  -not -path "*/legal/*" \
  -not -path "*/man/*" \
  -exec codesign -f --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain {} \;

% codesign -f --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain my-app.app/Contents/runtime

% codesign -f --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain my-app.app

All tests work:

% codesign -vvv --deep --strict my-app.app/Contents/runtime 
my-app.app/Contents/runtime: valid on disk
my-app.app/Contents/runtime: satisfies its Designated Requirement
% codesign -vvv --deep --strict my-app.app/                
--prepared:/private/tmp/my-app.app/Contents/MacOS/libapplauncher.dylib
--validated:/private/tmp/my-app.app/Contents/MacOS/libapplauncher.dylib
my-app.app/: valid on disk
my-app.app/: satisfies its Designated Requirement
% spctl -a -t exec -vv my-app.app          
my-app.app: accepted
source=Developer ID
origin=XXX

Does it run?

% my-app.app/Contents/MacOS/my-app 

Yes!

Does it notarize?

Status: success
Status Code: 0
Status Message: Package Approved

Hurrah!

Summary for those bundling a JRE:

• jpackage signing is broken right now, if you want to get something notarized
• You must sign your own code.
• You must re-sign the JRE. Use -f to force the signature.
• You must specify entitlements in all signing calls

I was able to follow your steps however I have a library and even with
<key>com.apple.security.cs.disable-library-validation</key> <true/>

I get this error:

Exception in thread "JavaFX Application Thread" java.lang.UnsatisfiedLinkError: /private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm0000gp/T/JxBrowser/7.5/libbrowsercore_toolkit.dylib: dlopen(/private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm0000gp/T/JxBrowser/7.5/libbrowsercore_toolkit.dylib, 1): no suitable image found. Did find:
/private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm0000gp/T/JxBrowser/7.5/libbrowsercore_toolkit.dylib: code signature in (/private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm0000gp/T/JxBrowser/7.5/libbrowsercore_toolkit.dylib) not valid for use in process using Library Validation: mapping process and mapped file (non-platform) have different Team IDs

Does this mean the library I have also needs that entitlement for it to work or is it something on my end?

The most frustrating part of the notarization process is that I've had to plumb this release process into my CI/CD pipeline. I wish apple would supply a test endpoint. I don't need it notarized, I just need to know if it is notarizable. Granted the difference is small, but a couple things make it uncomfortable.

1. If I consume an update to a 3rd party, I need an intake process that validates that the update is notarizable. By submitting that 3rd party for validation, I've now notarized that 3rd party using my companies creds, and my security folks think that isn't awesome.
2. I'm submitting things for notarization every day that I absolutely do not intend to provide to a customer, and I have to use credentials that that are authorized to do more than just test. Because those creds are now part of my pipeline, my security surface area for a breach in credentials is larger. So I want a test endpoint that uses no creds, or uses creds that are for testing purposes only.

Is anyone else running into the issue I am having @gravelld @dg76 I have tried creating an entitlement but that doesn't seem to disable library validation

@dcboy95 I'm sorry - I don't know how particular entitlements work with respect to coverage over the entire bundle. I found, with the code signing, I had to resign the entire library I shipped with, so maybe that means the entire codebase you ship with also has to have the entitlement? Sorry.

@dcboy95 I would think that you just have to resign the file "libbrowsercore_toolkit.dylib" using codesign and your own certificate. (I thought I had already posted this suggestion here but I cannot find any response from me.) The error just seems to indicate that the library has a different signature than the rest of the application. And I think everything has to have the same signature to ensure that no one else put anything into it. So just try to run codesign on "libbrowsercore_toolkit.dylib". Does that fix it?

@dg76 Unfortunately that didn't work. With the third party library it reinstalls itself if there is a different version. So when I codesign that file, it sees it as a old file and downloads a new one, replacing the modified one. Resulting in the same error. I thought the entitlement com.apple.security.cs.disable-library-validation would fix this issue however it doesn't seem to.

@dcboy95 I think this won't work. I think the purpose of Apple's notarization system is to ensure that the developer has confirmed that all parts of his app have been tested and are fine. Loading parts from other developers during runtime, which have not been tested and confirmed by the developer, are probably not allowed. Can't you just disable the automatic download function?

@dg76 Thanks for the information, I will have to research their documentation to see if this is a possibility. Thanks again

AdoptOpenJDK 14+36 is out which is fully notarized. Please report back in case of troubles.

A fully notarized JDK 8 is still in the works. We hope to get this included in the next quarterly CPU (closest Tuesday to the 17th of April).

The patches required passed some test runs (including the TCK), but more validation is necessary. @gdams plans to publish the current state so that we can provide builds for testing in the not so distant future.

@aahlenst is there any plans for JDK 11?

@dcboy95 A fully notarized JDK 11 will be published as part of the next quarterly CPU (shortly after the closest Tuesday to the 17th of April if I remember Oracle's rule correctly). In the meantime, you can grab a nightly build of JDK 11 on https://adoptopenjdk.net/nightly.html?variant=openjdk11&jvmVariant=hotspot and report back if it doesn't work.

Hi I tried using jdk-11.0.7+7 for the installer but still [1] fails with th error "The signature of the binary is invalid"

[1] /Contents/MacOS/libjli.dylib

@NishikaDeSilva try running this:

codesign --verbose=4 --deep --force -s "Developer ID Application: MyTeam (XXXX)" installer.jdk

@gdams I tried your solution.

command: codesign --verbose=4 --deep --force -s "Developer ID Application: abc (xxxxx)" jdk-11.0.7+7

output:
jdk-11.0.7+7: replacing existing signature
jdk-11.0.7+7: resource fork, Finder information, or similar detritus not allowed

But it indicates the following error...
jdk-11.0.7+7: code has no resources but signature indicates they must be present.

Am I doing something wrong ?

I tried 11.0.7+7 from the nightly build. Notarization passes and the application comes up successfully. However, it seems that binaries (dylib) are now looked up in the executed jar bundle only by any native load that is used by JNA. As a result our application now receives UnsatisfiedLinkErrors when trying to access dylib installed on the system. This was working before.

@MoxxiManagarm Are the dylibs signed? Check with codesign -v -v /path/to/dylib.

@aahlenst I doubt, those are 3rd party dylibs (device drivers) installed on the system, they are not part of our application. I also have the entitlement active com.apple.security.cs.disable-library-validation, that shouldn't be an issue.

The lib exists within the directory /usr/local/lib/

Using the nightly build of JDK 11's JRE, I have the same issue as NishikaDeSilva. I've tested nightly builds of JRE 13 and 14 as well for good measure.

I don't know if any of this will be helpful, but here are my notes.

Running codesign -dvvv libjli.dylib to check the signature results in this.

Executable=[...]/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
Hash type=sha256 size=32
CandidateCDHash sha1=512c6006363d2928665d9d135f360f974fe66d27
CandidateCDHashFull sha1=512c6006363d2928665d9d135f360f974fe66d27
CandidateCDHash sha256=1157d57e9849eb161251e3a4bca6e2ab7200eaa1
CandidateCDHashFull sha256=1157d57e9849eb161251e3a4bca6e2ab7200eaa11cf4d1f13ae558f0a8ae207e
Hash choices=sha1,sha256
CMSDigest=2727b2d669fee540fd5848fffba07d583d737065d4f28c205530b29f44dfb347
CMSDigestType=2
CDHash=1157d57e9849eb161251e3a4bca6e2ab7200eaa1
Signature size=9037
Authority=Developer ID Application: London Jamocha Community CIC (VDX7B37674)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Mar 31, 2020 at 8:44:15 AM
Info.plist=not bound
TeamIdentifier=VDX7B37674
Runtime Version=10.14.0
Sealed Resources=none
Internal requirements count=1 size=168

Verifying the signature with spctl -a -vv libjli.dylib results in this:
libjli.dylib: code has no resources but signature indicates they must be present

I can't find any good documentation on that error, but it seems to have something to do with "sealed resources", which the signature above says is none. Doesn't make much sense.

Attempting to codesign the file myself results in this:
resource fork, Finder information, or similar detritus not allowed

All existing documentation on that error says that it's caused by extended attributes on the file. Specifically, com.apple.FinderInfo and com.apple.ResourceFork. But ls -l@ libjli.dylib and xattr -l libjli.dylib lists no xattributes.

Curiously, moving the file to another location (anywhere outside the Contents/MacOS folder) or changing the file extension to something other than .dylib will make codesigning and signature verification pass normally, without either of the above nonsensical errors. The codesign mechanism must be taking the location of the file into account as well, causing it to differ from the results of the file at Contents/Home/lib/jli/libjli.dylib.

Any update on the driver dylib which is not found within /usr/local/lib/ after notarization (nightly build)?

Verifying the signature with spctl -a -vv libjli.dylib results in this:
libjli.dylib: code has no resources but signature indicates they must be present

@justin-espedal try running this on the top-level directory:

xattr -cr .
codesign --verbose=4 --deep --force -s "Developer ID Application: MyTeam (XXXX)" adoptopenjdk-11.jdk 

output:
jdk-11.0.7+7: replacing existing signature
jdk-11.0.7+7: resource fork, Finder information, or similar detritus not allowed

@NishikaDeSilva run this on the directory before running the codesign command:

xattr -cr .

That does work. No need for the recursive -cr, just removing com.apple.FinderInfo from the top-level folder is enough. It makes sense that the FinderInfo attribute on the top-level folder is what interferes with codesigning of the entire package.

Regardless of whether that xattr is present or not, the libjli.dylib still can't be codesigned on its own. Does the codesign mechanism requires dylib's in that specific location to verify something with the containing packages code signature? If that's the case (or perhaps regardless of that), why isn't the whole package simply codesigned by default?

I'd certainly prefer not to codesign the entire JRE's code if I don't have to.

@gadams @aahlenst Any update on the notarized JDK 1.8? Are we releasing it on Apr 17th? Is there an earlier kit to try out?

Next week, there will be a 8u252 without notarization and hardened runtime first. Afterwards, we are going to flip the switches and build one with notarization and hardened runtime. Additional information will follow. I do not know whether there is already a binary that is ready for testing by others.

Will 8u252 include libAppleScriptEngine.dylib that is built against later sdk so doesnt fail with 'The binary uses an SDK older than the 10.9 SDK', this would be most helpful,https://stackoverflow.com/questions/61208189/java-notarization-of-libapplescriptengine-dylib-failing-with-the-binary-uses-an

The long-awaited 8u252 is out, but it turned out almost all binaries in it were still built with sdk 10.8, which prevents successful notarization.
The JRE from https://ci.adoptopenjdk.net/view/work%20in%20progress/job/jdk8u-mac-x64-hotspot-notarized/10/ contained 10.14 binaries so we hoped the official 8u252 also will.

Next week, there will be a 8u252 without notarization and hardened runtime first. Afterwards, we are going to flip the switches and build one with notarization and hardened runtime.

Do you guys have a schedule for this you can share, please?

@meshcow Hard to estimate. That's why I gave no estimate in the first place. Pipelines with the regular builds are still running (for example, 14.0.1 with HotSpot and 11.0.7 with OpenJ9). The version with hardened runtime will be built afterwards.

@meshcow - we'll be building an 8u252.1 to test our Mac Os notarization patch, should be here in a day or two.

FYI I used BellSoft 8u252 to try and get a libAppleScriptEngine.dylib that is built against later sdk to allow notarization, and can confirm that worked.

Can also confirm I bundled AdoptJDk 11.0.7 JRE build and into my app and successfully notarized my application.

FYI I used BellSoft 8u252 to try and get a libAppleScriptEngine.dylib that is built against later sdk to allow notarization, and can confirm that worked.

Could you tell, please, what you are using to bundle jre with your app? When I use javapackager it says fxbundlerpath/Contents/MacOS/libpackager.dylib: is already signed.
And how do you do that with AdoptJDK 11?

I used Appbundler (InfinityKind fork) - https://github.com/TheInfiniteKind/appbundler/
I will try and post a full detailed answer on stackoveflow tomorrow

@as1an Added answer to my own question at https://stackoverflow.com/questions/58548736/notarize-existing-java-application-for-macos-catalina

Anyone has a J9 JVM 1.8 notarized build for us to test?

@meshcow Hard to estimate. That's why I gave no estimate in the first place. Pipelines with the regular builds are still running (for example, 14.0.1 with HotSpot and 11.0.7 with OpenJ9). The version with hardened runtime will be built afterwards.

@aahlenst Will this include J9 version of 1.8 JVM as well?

It's coming this week.

Great thanks!

A Notarized JDK8u Hotspot binary has been released today jdk8u252-b09.1

https://adoptopenjdk.net/archive.html?variant=openjdk8&jvmVariant=hotspot

Try it out and let us know if you have any issues!

OpenJ9 will also be out shortly

We were able to notarize our app with bundled hotspot 8u252-b09.1 JRE successfully.
Thank you guys very much!

@meshcow Does your app embed the JVM or it uses it externally? We are seeing runtime issue saying the signature is different in the JVM from our app signature.

@meshcow Does your app embed the JVM or it uses it externally? We are seeing runtime issue saying the signature is different in the JVM from our app signature.

The JVM is embedded (JNI), the app is signed by our cert. We didn't sign anything within JRE, as it turned out everything in it was signed already.
No issues so far.

@meshcow I know this is unrelated, and I apologize if this is not the right forum for this, but I have been struggling to get JNI working in a bundled app, and I was wondering if you could share any resources that helped you get there. All of the current java app bundlers I can find produce an un-hardened executable that prevents notarization, even when the JRE is notarizable.

Any help to get over this last hurdle would be much appreciated.

@addsomebass - We use standard by-the-book approach: a small launcher written in Objective C which uses Java Invocation API to load the JVM and start our [pure] Java app with it. The launcher gets put into the OSX app's directory under /Contents/MacOs. The JRE gets put there into java app folder under /Contents/[app-name]/jre.
The OSX app gets signed, and then it is ready to be sent for notrization. We use the following cmd-line args for codesign: --strict --timestamp --entitlements entitlements.plist --force --deep --options runtime, and the entitlemenst.plist contents is as in this answer: https://stackoverflow.com/a/58553559.

So the only thing I could advice is to create your own launcher. It shouldn't be that hard, there are plenty of examples you can find, e.g. https://github.com/search?l=Objective-C&q=JNI_createJavaVM&type=Code

@addsomebass I think you don't need an own launcher. I am using JNI in a normal Java program that is bundled using the Java packager jpackage of Java 14. You can find my steps here: https://blog.dgunia.de/2020/02/12/signed-macos-programs-with-java-14/ It describes only the signing, not the JNI part. But I have created a normal JNI dylib file that is also signed during that process. It works fine so far, it was possible to notarize it.

@addsomebass @dg76 Java 8 is our case, not 14

@meshcow @dg76 thanks for the tips. We need to use Java 8 as well due to RMI changes.

Thanks for supporting notarization now. But where ist javapackager in package? I can only find "normal" jdk8 build without javapackager. Is there a full jdk with javapackager built in?

@gdams @aahlenst
We used the Open J9 hardened version released last week and we got this error from Apple during notarization:

{ "severity": "error", "code": null, "path": "/jre/Contents/MacOS/libjli.dylib", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" }

It says libjli.dylib has no signature, but I believe its a link file?

We also tried this command

File downloaded - OpenJDK8U-jre_x64_mac_openj9_macosXL_8u252b09_openj9-0.20.0.tar.gz* unzipped it to the folder jdk8u252-b09-jre-j9 and then checked signature -

codesign -vvvv jdk8u252-b09-jre-j9jdk8u252-b09-jre-j9/: code has no resources but signature indicates they must be present

Not sure if both are related. Is there a fix for this?

Thank you.

If you need help, please open issues in https://github.com/adoptopenjdk/openjdk-support/.