Notarization and Java Apps
For beaTunes things are a little different, as it uses Java as runtime. So far Oracle (or anybody else I know of) has not shipped a Java runtime that has been compiled against macOS SDK 10.9 or later and the hardened macOS runtime. Additionally, Oracle’s Java executables are not signed with suitable signature algorithms (see Bug JDK-8223671 for a detailed list of notarization failures). All these are requirements for notarization. There is no way for me to ship a notarized version of beaTunes before they are addressed and unless I want to roll my own version of Java (I don’t!!), I simply have to wait and hope that someone at Oracle will take pity on Mac devs.
It is increasingly difficult to be off the beaten path of using Apple’s preferred tools and frameworks.
“Uploading to Apple to Notarize” is the new “COMPILING!”
Previously:
- Updated Hardened Runtime Documentation
- What I Wish I’d Known Before Starting Notarize
- Security & Privacy in macOS 10.15 Beta
- macOS 10.14.5 Requires New Developers to Notarize
Update (2019-08-05): McCloud:
Handy reminder: Everything in your entire stack, up to and including your programming language’s runtime environment, is a liability.
Developers should make sure it’s their own Developer ID that signs libraries they ship inside their apps.
Also, OpenJDK 8 is rather old and new JDKs are properly built against macOS 10.9 or later.
We have enabled hardened runtime on our macOS binaries which will allow them to be bundled into applications and pass Apple’s Notarization tests. OpenJDK 11+ will work out of the box, OpenJDK8 needs a bit more work because it’s built on an older toolchain that the notarization test doesn’t support. We will be creating a second release of jdk-11.0.4+11 and jdk-12.0.2+10 which will have hardened runtime enabled.
4 Comments RSS · Twitter
The issue of the old SDK is a real problem, but the signature and hardened runtime are not. Notarizing involves replacing any existing signing with a code-signature in the main developer's identity anyway, and that's the point at which complying with the hardened runtime is done.
As Shane said, the only real issue here is the old runtime. We currently sign and notarize an app that includes JDK11 from AdoptOpenJDK without issue (other than initially having to more or less guess and check which hardened runtime exceptions were required for the JDK). They are targeting a later version of macOS than Oracle is with JDK8. We bundle also bundle native libraries inside the JAR from some of our dependencies, so part of our signing workflow is to extract the JAR, sign everything, and re-JAR the files.
The real issue we have is 80% of the time spent in preparing release packages is waiting for the Notarization service to give us the receipt to staple to the bundle.
I haven’t checked, it it’s possible AdoptOpenJDK is building JDK8 against a newer version of macOS than Oracle is; might be worth checking out for those who are stuck on JDK8.
I’m surprised you can just ship Oracle JRE inside your own app bundle - especially since the commercial licensing changes a few months ago. It looks like OpenJDK builds against 10.11, according to their wiki, but switching and going that route would undeniably be a whole world of hurt. Probably easier to rewrite it in Swift tbh. I do feel for devs that are hit by these changes - also including devs who can’t really afford the $99 every year.
"It is increasingly difficult to be off the beaten path of using Apple’s preferred tools and frameworks." which is no doubt the idea.
