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 <[email protected]> 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
