RFR: JDK-8237607: [macos] Signing app bundle with jpackage fails if runtime is already signed

[James Elliott]

I am glad to see that people are making progress on this front. Did you see the points I raised about the new arguments and inputs that need to be provided in order to build code-signed packages that can pass Apple’s current notarization requirements in Catalina? I am currently successfully notarizing a Java disk image created by the early access version of jpackage, but I need to do the signing and notarizing myself because jpackage does not yet support specifying use of the hardened runtime, nor the necessary entitlements for the JVM to run properly in that hardened environment. I would be happy to share what I found works whenever that might be helpful.

Cheers,

	-James

On 1/22/2020 11:37 PM, Alexander Matveev wrote:
Please review the jpackage fix for bug [1] at [2].
- Fixed by forcing signing even if runtime already signed. - Original implementation was not taken in consideration that runtime can be signed (JDK itself is signed from which jpackage is used or runtime provided via --runtime-image). - Signature of binaries files in runtime will not be change, with this fix we will generate new _CodeSignature/CodeResources file which contains signatures of all files inside runtime folder signed with user provided certificate.
[1] https://bugs.openjdk.java.net/browse/JDK-8237607
[2] http://cr.openjdk.java.net/~almatvee/8237607/webrev.00/
Thanks, Alexander