jpackage and macOS Catalina notarization

James Elliott james at deepsymmetry.org
Wed Jan 15 05:57:55 UTC 2020


I can report that this question is no longer theoretical. As of this morning, Apple began rejecting notarization of my disk images that had been code-signed by jpackage for lacking secure timestamps and not using the hardened runtime. So jpackage-signed applications are no longer accepted by macOS Catalina.

Using the resources below, I found a way to forcibly re-sign all the executables in my disk image with timestamps and the hardened runtime, along with the entitlements required for the JVM to work. I hope that jpackage can be updated soon to do this on its own, because not all developers are going to be as doggedly persistent as I have in figuring out how to get Java applications packaged as working Mac applications. If anyone would like to see the exact script that is now working for me (I am using GitHub Actions to continuously deploy my releases so I can just point you at a file in the public repository), or ask any follow-up questions, I would be happy to help.

I also notice that the background image and Applications folder alias that are supposed to be in the disk image don’t seem to work in Catalina, so I may give up on having jpackage create my disk images as well, and do that using native tools, until that can be fixed. (I realize it is in early access still, and hope these issues are being worked on.)

A colleague who was creating my Windows builds reports that there are Wix settings missing in the jpackage Windows MSI installers that will prevent automatic upgrading/replacement. I am trying to encourage him to join this mailing list so he can share the details, but if anyone would like details before he does I can relay them.

Thanks,

	-James

> On Jan 4, 2020, at 00:50, James Elliott <james at deepsymmetry.org> wrote:
> 
> Hello, everyone, I finally found this list, as well as a way to search it, and so hope this question is relevant and appropriate and not already answered.
> 
> For some time I have been using an old javapackager along with a newer release of jlink to create native macOS installers for a free, open-source Swing application, and am very excited to see that JEP-343 is finally on the horizon so I soon can stop relying on the ancient javapackager. Still, its ability to code sign my installer DMG has been very beneficial to my less-Java-savvy users (generally musicians and light/laser/video technicians running stage shows).
> 
> Apple’s current operating system, Catalina, adds still more hoops for developers to jump through in order to enable their software to be run without complaint and complexity: It needs to be notarized (uploaded to Apple and scanned for malicious code and other unsafe properties). I am not asking if jpackage might assist with the notarization step any time soon; that is something that can be accomplished separately after the code-signed package or disk image has been produced.
> 
> The issue, however, is that for notarization to succeed, the code signing must be performed in a manner that causes the application to use the hardened runtime, and therefore a set of entitlements must be added in order for Java code to run successfully. (These requirements have been temporarily relaxed because so few developers were ready for them, but they will be returning soon.) I could not see any evidence in the jpackage documentation or help text that it could support these code signing options, specifically —timestamp, —options runtime, and —entitlements entitlements.plist (for full details on getting this process to work, I found the following two articles incredibly helpful: http://www.zarkonnen.com/signing_notarizing_catalina <http://www.zarkonnen.com/signing_notarizing_catalina> and http://kothar.net/macos_catalina_java_11 <http://kothar.net/macos_catalina_java_11> ).
> 
> Is this something that is on the radar for a future jpackage release? Failing that, is there a way to perform the code signing separately and still use jpackage to produce the disk image?
> 
> Thanks for any thoughts or insight you might be able to share,
> 
> 	-James



More information about the core-libs-dev mailing list