-
-
Notifications
You must be signed in to change notification settings - Fork 251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MacOS hardened runtime support #1130
Comments
when I try and add this flag I get the following error: |
@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. |
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 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/> |
@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:
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: |
@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. |
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? |
@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. |
Could you tell, please, what you are using to bundle jre with your app? When I use javapackager it says |
I used Appbundler (InfinityKind fork) - https://github.com/TheInfiniteKind/appbundler/ |
@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? |
@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 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. |
@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. |
@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. 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 |
Thanks for supporting notarization now. But where ist |
@gdams @aahlenst { "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 -
|
If you need help, please open issues in https://github.com/adoptopenjdk/openjdk-support/. |
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:
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
The text was updated successfully, but these errors were encountered: