jpackage MacOS Notarization
All, I am trying to notarize an app (built with jpackage) for MacOS. jpackage at first *seems* to properly sign all resources with the available --mac-sign options et cetera. Having said that, there are still remaining issues 1. The app cannot be properly installed (without hacks like xattr -d com.apple.quarantine /Applications/myAPP.app ). 2. I am also not able to properly notarize the app. According to online resources there seem to exist issues in *past* about notarization but according to [1, 2] the issues are fixed. As mentioned, I still have issues :-( Am I really the only one still having problems? Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without success) The issue seems to boil down to 2 errors (attached the error log from Apple notarization process). * app Folder * libjli.dylib I thought I better ask first on the mailing list before creating an actual bug report. Note1: I used to use the *old* javapackager that worked with the same signature/credentials. Note2: running jpackage without --mac-sign options causes many more errors in notarization (Hence, jpackage signs most resources but fails with some) Any help / hint appreciated. Thanks, -- Daniel [1] https://bugs.openjdk.java.net/browse/JDK-8257488 [2] https://bugs.openjdk.java.net/browse/JDK-8251892 ## APPLE LOG ## { "logFormatVersion": 1, "jobId": "...", "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "archiveFilename": "myAPP-21.07.28.dmg", "uploadDate": "2021-07-28T14:31:24Z", "sha256": "...", "ticketContents": null, "issues": [ { "severity": "error", "code": null, "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" }, { "severity": "error", "code": null, "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" } ] }
Full support for notarization in jpackage was added in JDK 17. Can you try an early access build of JDK 17 [1] and see if that works for you? -- Kevin [1] https://jdk.java.net/17 On 7/28/2021 8:27 AM, Daniel Peintner wrote:
All,
I am trying to notarize an app (built with jpackage) for MacOS.
jpackage at first *seems* to properly sign all resources with the available --mac-sign options et cetera.
Having said that, there are still remaining issues 1. The app cannot be properly installed (without hacks like xattr -d com.apple.quarantine /Applications/myAPP.app ). 2. I am also not able to properly notarize the app.
According to online resources there seem to exist issues in *past* about notarization but according to [1, 2] the issues are fixed.
As mentioned, I still have issues :-( Am I really the only one still having problems?
Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without success)
The issue seems to boil down to 2 errors (attached the error log from Apple notarization process). * app Folder * libjli.dylib
I thought I better ask first on the mailing list before creating an actual bug report.
Note1: I used to use the *old* javapackager that worked with the same signature/credentials. Note2: running jpackage without --mac-sign options causes many more errors in notarization (Hence, jpackage signs most resources but fails with some)
Any help / hint appreciated.
Thanks,
-- Daniel
[1] https://bugs.openjdk.java.net/browse/JDK-8257488 [2] https://bugs.openjdk.java.net/browse/JDK-8251892
## APPLE LOG ##
{ "logFormatVersion": 1, "jobId": "...", "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "archiveFilename": "myAPP-21.07.28.dmg", "uploadDate": "2021-07-28T14:31:24Z", "sha256": "...", "ticketContents": null, "issues": [ { "severity": "error", "code": null, "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" }, { "severity": "error", "code": null, "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" } ] }
Kevin, Andy, Thanks for your quick response. Full support for notarization in jpackage was added in JDK 17. Can you
try an early access build of JDK 17 [1] and see if that works for you?
I did try JDK17-ea-32 also with the same result. Since I do understand it is difficult reproduce the problem I put together a *very* simple test application which you can find in the "non-modular" branch here: https://github.com/danielpeintner/Java11Test/tree/non-modular It is a gradle project. It uses Java 11 to run but in build.gradle on line#83 [1] one can set the jpackage location (JDK17-ea-32 in this case). The process is as follows * ./gradlew build * ./gradlew jpackage // creates the dmg/pkg in folder build/jpackage * afterwards Apple notarization process can be started Note: notarization of dmg or pkg lead to the same failure. See [2] for the full log w.r.t. pkg. I hope this helps you to be able to reproduce the issue. Thanks for your investigations! -- Daniel [1] https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d... [2] https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904...
-- Kevin
On 7/28/2021 8:27 AM, Daniel Peintner wrote:
All,
I am trying to notarize an app (built with jpackage) for MacOS.
jpackage at first *seems* to properly sign all resources with the available --mac-sign options et cetera.
Having said that, there are still remaining issues 1. The app cannot be properly installed (without hacks like xattr -d com.apple.quarantine /Applications/myAPP.app ). 2. I am also not able to properly notarize the app.
According to online resources there seem to exist issues in *past* about notarization but according to [1, 2] the issues are fixed.
As mentioned, I still have issues :-( Am I really the only one still having problems?
Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without success)
The issue seems to boil down to 2 errors (attached the error log from Apple notarization process). * app Folder * libjli.dylib
I thought I better ask first on the mailing list before creating an actual bug report.
Note1: I used to use the *old* javapackager that worked with the same signature/credentials. Note2: running jpackage without --mac-sign options causes many more errors in notarization (Hence, jpackage signs most resources but fails with some)
Any help / hint appreciated.
Thanks,
-- Daniel
[1] https://bugs.openjdk.java.net/browse/JDK-8257488 [2] https://bugs.openjdk.java.net/browse/JDK-8251892
## APPLE LOG ##
{ "logFormatVersion": 1, "jobId": "...", "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "archiveFilename": "myAPP-21.07.28.dmg", "uploadDate": "2021-07-28T14:31:24Z", "sha256": "...", "ticketContents": null, "issues": [ { "severity": "error", "code": null, "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" }, { "severity": "error", "code": null, "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" } ] }
The 'build.gradle' in this branch has --mac-signing-key-user-name commented out.
installerOptions += [ '--mac-sign', // '--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name', System.getenv('SIGNING_KEY_USER_NAME'), // '--mac-signing-keychain', System.getenv('SIGNING_KEYCHAIN_PATH') ]
clearly this cannot work, I assume you were just trying things ... What is the full name of the certificate you intended to use, what keychain is it shown in "Keychain Access", and what are you normal values for your environment variables: 'SIGNING_KEY_USER_NAME' and 'SIGNING_KEYCHAIN_PATH' ? /Andy On 7/29/2021 4:36 AM, Daniel Peintner wrote:
Kevin, Andy,
Thanks for your quick response.
Full support for notarization in jpackage was added in JDK 17. Can you try an early access build of JDK 17 [1] and see if that works for you?
I did try JDK17-ea-32 also with the same result.
Since I do understand it is difficult reproduce the problem I put together a *very* simple test application which you can find in the "non-modular" branch here: https://github.com/danielpeintner/Java11Test/tree/non-modular <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/tree/non-modular__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE2ZACADEA$>
It is a gradle project. It uses Java 11 to run but in build.gradle on line#83[1] one can set the jpackage location (JDK17-ea-32 in this case).
The process is as follows * ./gradlew build * ./gradlew jpackage // creates the dmg/pkg in folder build/jpackage * afterwards Apple notarization process can be started
Note: notarization of dmg or pkg lead to the same failure. See [2] for the full log w.r.t. pkg.
I hope this helps you to be able to reproduce the issue.
Thanks for your investigations!
-- Daniel
[1] https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d... <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle*L83__;Iw!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE03e0qq7A$> [2] https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904... <https://urldefense.com/v3/__https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs*2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w*2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh*2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX*2FN6zZoyz73I*3D__;JSUlJSU!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0bBsP8Hg$>
-- Kevin
[1] https://jdk.java.net/17 <https://urldefense.com/v3/__https://jdk.java.net/17__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0PgDN5dA$>
On 7/28/2021 8:27 AM, Daniel Peintner wrote: > All, > > I am trying to notarize an app (built with jpackage) for MacOS. > > jpackage at first *seems* to properly sign all resources with the available > --mac-sign options et cetera. > > Having said that, there are still remaining issues > 1. The app cannot be properly installed > (without hacks like xattr -d com.apple.quarantine /Applications/myAPP.app > ). > 2. I am also not able to properly notarize the app. > > According to online resources there seem to exist issues in *past* about > notarization but according to [1, 2] the issues are fixed. > > As mentioned, I still have issues :-( > Am I really the only one still having problems? > > Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without success) > > The issue seems to boil down to 2 errors (attached the error log from Apple > notarization process). > * app Folder > * libjli.dylib > > I thought I better ask first on the mailing list before creating an actual > bug report. > > Note1: I used to use the *old* javapackager that worked with the same > signature/credentials. > Note2: running jpackage without --mac-sign options causes many more errors > in notarization (Hence, jpackage signs most resources but fails with some) > > Any help / hint appreciated. > > Thanks, > > -- Daniel > > [1] https://bugs.openjdk.java.net/browse/JDK-8257488 <https://bugs.openjdk.java.net/browse/JDK-8257488> > [2] https://bugs.openjdk.java.net/browse/JDK-8251892 <https://bugs.openjdk.java.net/browse/JDK-8251892> > > > > ## APPLE LOG ## > > { > "logFormatVersion": 1, > "jobId": "...", > "status": "Invalid", > "statusSummary": "Archive contains critical validation errors", > "statusCode": 4000, > "archiveFilename": "myAPP-21.07.28.dmg", > "uploadDate": "2021-07-28T14:31:24Z", > "sha256": "...", > "ticketContents": null, > "issues": [ > { > "severity": "error", > "code": null, > "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP", > "message": "The signature of the binary is invalid.", > "docUrl": null, > "architecture": "x86_64" > }, > { > "severity": "error", > "code": null, > "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib", > "message": "The signature of the binary is invalid.", > "docUrl": null, > "architecture": "x86_64" > } > ] > }
Hi Andy, Since I don't know your setup I did not put anything there. '--mac-sign' is enough to use the defaults in my setup. It looks for the signing keys installed on my machine that start with "Developer ID Application " similar to '--mac-signing-key-user-name', 'Developer ID Application: ' etc. If you want to test it you need to add your credentials which I do not know. Hope this clarifies things, -- Daniel On Thu, Jul 29, 2021 at 3:29 PM Andy Herrick <andy.herrick@oracle.com> wrote:
The 'build.gradle' in this branch has --mac-signing-key-user-name commented out.
installerOptions += [ '--mac-sign', // '--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name', System.getenv('SIGNING_KEY_USER_NAME'), // '--mac-signing-keychain', System.getenv('SIGNING_KEYCHAIN_PATH') ]
clearly this cannot work, I assume you were just trying things ...
What is the full name of the certificate you intended to use, what keychain is it shown in "Keychain Access", and what are you normal values for your environment variables: 'SIGNING_KEY_USER_NAME' and 'SIGNING_KEYCHAIN_PATH' ?
/Andy On 7/29/2021 4:36 AM, Daniel Peintner wrote:
Kevin, Andy,
Thanks for your quick response.
Full support for notarization in jpackage was added in JDK 17. Can you
try an early access build of JDK 17 [1] and see if that works for you?
I did try JDK17-ea-32 also with the same result.
Since I do understand it is difficult reproduce the problem I put together a *very* simple test application which you can find in the "non-modular" branch here: https://github.com/danielpeintner/Java11Test/tree/non-modular <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/tree/non-modular__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE2ZACADEA$>
It is a gradle project. It uses Java 11 to run but in build.gradle on line#83 [1] one can set the jpackage location (JDK17-ea-32 in this case).
The process is as follows * ./gradlew build * ./gradlew jpackage // creates the dmg/pkg in folder build/jpackage * afterwards Apple notarization process can be started
Note: notarization of dmg or pkg lead to the same failure. See [2] for the full log w.r.t. pkg.
I hope this helps you to be able to reproduce the issue.
Thanks for your investigations!
-- Daniel
[1] https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d... <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle*L83__;Iw!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE03e0qq7A$> [2] https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904... <https://urldefense.com/v3/__https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs*2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w*2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh*2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX*2FN6zZoyz73I*3D__;JSUlJSU!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0bBsP8Hg$>
-- Kevin
[1] https://jdk.java.net/17 <https://urldefense.com/v3/__https://jdk.java.net/17__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0PgDN5dA$>
On 7/28/2021 8:27 AM, Daniel Peintner wrote:
All,
I am trying to notarize an app (built with jpackage) for MacOS.
jpackage at first *seems* to properly sign all resources with the available --mac-sign options et cetera.
Having said that, there are still remaining issues 1. The app cannot be properly installed (without hacks like xattr -d com.apple.quarantine /Applications/myAPP.app ). 2. I am also not able to properly notarize the app.
According to online resources there seem to exist issues in *past* about notarization but according to [1, 2] the issues are fixed.
As mentioned, I still have issues :-( Am I really the only one still having problems?
Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without success)
The issue seems to boil down to 2 errors (attached the error log from Apple notarization process). * app Folder * libjli.dylib
I thought I better ask first on the mailing list before creating an actual bug report.
Note1: I used to use the *old* javapackager that worked with the same signature/credentials. Note2: running jpackage without --mac-sign options causes many more errors in notarization (Hence, jpackage signs most resources but fails with some)
Any help / hint appreciated.
Thanks,
-- Daniel
[1] https://bugs.openjdk.java.net/browse/JDK-8257488 [2] https://bugs.openjdk.java.net/browse/JDK-8251892
## APPLE LOG ##
{ "logFormatVersion": 1, "jobId": "...", "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "archiveFilename": "myAPP-21.07.28.dmg", "uploadDate": "2021-07-28T14:31:24Z", "sha256": "...", "ticketContents": null, "issues": [ { "severity": "error", "code": null, "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" }, { "severity": "error", "code": null, "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" } ] }
sorry - code looks for certificate key starting with: "Developer ID Application: " + <value of mac-signing-key-user-name> in order to not have to put full user name in. I missed that that with null user name that causes it to look for anything starting with "Developer ID Application: " (same thing with "Developer ID Installer: " for .pkg signing). And macos looks at the non-default keychains as well as the default ones when no keychain is specified. /Andy On 7/29/2021 10:00 AM, Daniel Peintner wrote:
Hi Andy,
Since I don't know your setup I did not put anything there.
'--mac-sign' is enough to use the defaults in my setup.
It looks for the signing keys installed on my machine that start with "Developer ID Application " similar to '--mac-signing-key-user-name', 'Developer ID Application: ' etc.
If you want to test it you need to add your credentials which I do not know.
Hope this clarifies things,
-- Daniel
On Thu, Jul 29, 2021 at 3:29 PM Andy Herrick <andy.herrick@oracle.com <mailto:andy.herrick@oracle.com>> wrote:
The 'build.gradle' in this branch has --mac-signing-key-user-name commented out.
installerOptions += [ '--mac-sign', // '--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name', System.getenv('SIGNING_KEY_USER_NAME'), // '--mac-signing-keychain', System.getenv('SIGNING_KEYCHAIN_PATH') ]
clearly this cannot work, I assume you were just trying things ...
What is the full name of the certificate you intended to use, what keychain is it shown in "Keychain Access", and what are you normal values for your environment variables: 'SIGNING_KEY_USER_NAME' and 'SIGNING_KEYCHAIN_PATH' ?
/Andy
On 7/29/2021 4:36 AM, Daniel Peintner wrote:
Kevin, Andy,
Thanks for your quick response.
Full support for notarization in jpackage was added in JDK 17. Can you try an early access build of JDK 17 [1] and see if that works for you?
I did try JDK17-ea-32 also with the same result.
Since I do understand it is difficult reproduce the problem I put together a *very* simple test application which you can find in the "non-modular" branch here: https://github.com/danielpeintner/Java11Test/tree/non-modular <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/tree/non-modular__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE2ZACADEA$>
It is a gradle project. It uses Java 11 to run but in build.gradle on line#83[1] one can set the jpackage location (JDK17-ea-32 in this case).
The process is as follows * ./gradlew build * ./gradlew jpackage // creates the dmg/pkg in folder build/jpackage * afterwards Apple notarization process can be started
Note: notarization of dmg or pkg lead to the same failure. See [2] for the full log w.r.t. pkg.
I hope this helps you to be able to reproduce the issue.
Thanks for your investigations!
-- Daniel
[1] https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d... <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle*L83__;Iw!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE03e0qq7A$> [2] https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904... <https://urldefense.com/v3/__https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs*2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w*2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh*2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX*2FN6zZoyz73I*3D__;JSUlJSU!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0bBsP8Hg$>
-- Kevin
[1] https://jdk.java.net/17 <https://urldefense.com/v3/__https://jdk.java.net/17__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0PgDN5dA$>
On 7/28/2021 8:27 AM, Daniel Peintner wrote: > All, > > I am trying to notarize an app (built with jpackage) for MacOS. > > jpackage at first *seems* to properly sign all resources with the available > --mac-sign options et cetera. > > Having said that, there are still remaining issues > 1. The app cannot be properly installed > (without hacks like xattr -d com.apple.quarantine /Applications/myAPP.app > ). > 2. I am also not able to properly notarize the app. > > According to online resources there seem to exist issues in *past* about > notarization but according to [1, 2] the issues are fixed. > > As mentioned, I still have issues :-( > Am I really the only one still having problems? > > Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without success) > > The issue seems to boil down to 2 errors (attached the error log from Apple > notarization process). > * app Folder > * libjli.dylib > > I thought I better ask first on the mailing list before creating an actual > bug report. > > Note1: I used to use the *old* javapackager that worked with the same > signature/credentials. > Note2: running jpackage without --mac-sign options causes many more errors > in notarization (Hence, jpackage signs most resources but fails with some) > > Any help / hint appreciated. > > Thanks, > > -- Daniel > > [1] https://bugs.openjdk.java.net/browse/JDK-8257488 <https://bugs.openjdk.java.net/browse/JDK-8257488> > [2] https://bugs.openjdk.java.net/browse/JDK-8251892 <https://bugs.openjdk.java.net/browse/JDK-8251892> > > > > ## APPLE LOG ## > > { > "logFormatVersion": 1, > "jobId": "...", > "status": "Invalid", > "statusSummary": "Archive contains critical validation errors", > "statusCode": 4000, > "archiveFilename": "myAPP-21.07.28.dmg", > "uploadDate": "2021-07-28T14:31:24Z", > "sha256": "...", > "ticketContents": null, > "issues": [ > { > "severity": "error", > "code": null, > "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP", > "message": "The signature of the binary is invalid.", > "docUrl": null, > "architecture": "x86_64" > }, > { > "severity": "error", > "code": null, > "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib", > "message": "The signature of the binary is invalid.", > "docUrl": null, > "architecture": "x86_64" > } > ] > }
Hi Andy,
sorry - code looks for certificate key starting with: "Developer ID Application: " + <value of mac-signing-key-user-name> in order to not have to put full user name in. I missed that that with null user name that causes it to look for anything starting with "Developer ID Application: " (same thing with "Developer ID Installer: " for .pkg signing). And macos looks at the non-default keychains as well as the default ones when no keychain is specified.
Thanks for your feedback and yes in the simple case (with one certificate installed) it works without any further information. May I ask you whether you were able to reproduce the issue? Is there anything I can do to help? Thanks, -- Daniel
/Andy On 7/29/2021 10:00 AM, Daniel Peintner wrote:
Hi Andy,
Since I don't know your setup I did not put anything there.
'--mac-sign' is enough to use the defaults in my setup.
It looks for the signing keys installed on my machine that start with "Developer ID Application " similar to '--mac-signing-key-user-name', 'Developer ID Application: ' etc.
If you want to test it you need to add your credentials which I do not know.
Hope this clarifies things,
-- Daniel
On Thu, Jul 29, 2021 at 3:29 PM Andy Herrick <andy.herrick@oracle.com> wrote:
The 'build.gradle' in this branch has --mac-signing-key-user-name commented out.
installerOptions += [ '--mac-sign', // '--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name', System.getenv('SIGNING_KEY_USER_NAME'), // '--mac-signing-keychain', System.getenv('SIGNING_KEYCHAIN_PATH') ]
clearly this cannot work, I assume you were just trying things ...
What is the full name of the certificate you intended to use, what keychain is it shown in "Keychain Access", and what are you normal values for your environment variables: 'SIGNING_KEY_USER_NAME' and 'SIGNING_KEYCHAIN_PATH' ?
/Andy On 7/29/2021 4:36 AM, Daniel Peintner wrote:
Kevin, Andy,
Thanks for your quick response.
Full support for notarization in jpackage was added in JDK 17. Can you
try an early access build of JDK 17 [1] and see if that works for you?
I did try JDK17-ea-32 also with the same result.
Since I do understand it is difficult reproduce the problem I put together a *very* simple test application which you can find in the "non-modular" branch here: https://github.com/danielpeintner/Java11Test/tree/non-modular <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/tree/non-modular__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE2ZACADEA$>
It is a gradle project. It uses Java 11 to run but in build.gradle on line#83 [1] one can set the jpackage location (JDK17-ea-32 in this case).
The process is as follows * ./gradlew build * ./gradlew jpackage // creates the dmg/pkg in folder build/jpackage * afterwards Apple notarization process can be started
Note: notarization of dmg or pkg lead to the same failure. See [2] for the full log w.r.t. pkg.
I hope this helps you to be able to reproduce the issue.
Thanks for your investigations!
-- Daniel
[1] https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d... <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle*L83__;Iw!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE03e0qq7A$> [2] https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904... <https://urldefense.com/v3/__https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs*2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w*2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh*2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX*2FN6zZoyz73I*3D__;JSUlJSU!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0bBsP8Hg$>
-- Kevin
[1] https://jdk.java.net/17 <https://urldefense.com/v3/__https://jdk.java.net/17__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0PgDN5dA$>
On 7/28/2021 8:27 AM, Daniel Peintner wrote:
All,
I am trying to notarize an app (built with jpackage) for MacOS.
jpackage at first *seems* to properly sign all resources with the available --mac-sign options et cetera.
Having said that, there are still remaining issues 1. The app cannot be properly installed (without hacks like xattr -d com.apple.quarantine /Applications/myAPP.app ). 2. I am also not able to properly notarize the app.
According to online resources there seem to exist issues in *past* about notarization but according to [1, 2] the issues are fixed.
As mentioned, I still have issues :-( Am I really the only one still having problems?
Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without success)
The issue seems to boil down to 2 errors (attached the error log from Apple notarization process). * app Folder * libjli.dylib
I thought I better ask first on the mailing list before creating an actual bug report.
Note1: I used to use the *old* javapackager that worked with the same signature/credentials. Note2: running jpackage without --mac-sign options causes many more errors in notarization (Hence, jpackage signs most resources but fails with some)
Any help / hint appreciated.
Thanks,
-- Daniel
[1] https://bugs.openjdk.java.net/browse/JDK-8257488 [2] https://bugs.openjdk.java.net/browse/JDK-8251892
## APPLE LOG ##
{ "logFormatVersion": 1, "jobId": "...", "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "archiveFilename": "myAPP-21.07.28.dmg", "uploadDate": "2021-07-28T14:31:24Z", "sha256": "...", "ticketContents": null, "issues": [ { "severity": "error", "code": null, "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" }, { "severity": "error", "code": null, "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" } ] }
I was having problems notarizing anything yesterday, but fixed them today. I can notarize my own test - but get failure when trying to notarize your app as built from non-modular branch of https://github.com/danielpeintner/Java11Test/ am looking into it ... /Andy On 8/2/2021 9:57 AM, Daniel Peintner wrote:
Hi Andy,
sorry - code looks for certificate key starting with: "Developer ID Application: " + <value of mac-signing-key-user-name> in order to not have to put full user name in. I missed that that with null user name that causes it to look for anything starting with "Developer ID Application: " (same thing with "Developer ID Installer: " for .pkg signing). And macos looks at the non-default keychains as well as the default ones when no keychain is specified.
Thanks for your feedback and yes in the simple case (with one certificate installed) it works without any further information.
May I ask you whether you were able to reproduce the issue?
Is there anything I can do to help?
Thanks,
-- Daniel
/Andy
On 7/29/2021 10:00 AM, Daniel Peintner wrote:
Hi Andy,
Since I don't know your setup I did not put anything there.
'--mac-sign' is enough to use the defaults in my setup.
It looks for the signing keys installed on my machine that start with "Developer ID Application " similar to '--mac-signing-key-user-name', 'Developer ID Application: ' etc.
If you want to test it you need to add your credentials which I do not know.
Hope this clarifies things,
-- Daniel
On Thu, Jul 29, 2021 at 3:29 PM Andy Herrick <andy.herrick@oracle.com <mailto:andy.herrick@oracle.com>> wrote:
The 'build.gradle' in this branch has --mac-signing-key-user-name commented out.
installerOptions += [ '--mac-sign', // '--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name', System.getenv('SIGNING_KEY_USER_NAME'), // '--mac-signing-keychain', System.getenv('SIGNING_KEYCHAIN_PATH') ]
clearly this cannot work, I assume you were just trying things ...
What is the full name of the certificate you intended to use, what keychain is it shown in "Keychain Access", and what are you normal values for your environment variables: 'SIGNING_KEY_USER_NAME' and 'SIGNING_KEYCHAIN_PATH' ?
/Andy
On 7/29/2021 4:36 AM, Daniel Peintner wrote:
Kevin, Andy,
Thanks for your quick response.
Full support for notarization in jpackage was added in JDK 17. Can you try an early access build of JDK 17 [1] and see if that works for you?
I did try JDK17-ea-32 also with the same result.
Since I do understand it is difficult reproduce the problem I put together a *very* simple test application which you can find in the "non-modular" branch here: https://github.com/danielpeintner/Java11Test/tree/non-modular <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/tree/non-modular__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE2ZACADEA$>
It is a gradle project. It uses Java 11 to run but in build.gradle on line#83[1] one can set the jpackage location (JDK17-ea-32 in this case).
The process is as follows * ./gradlew build * ./gradlew jpackage // creates the dmg/pkg in folder build/jpackage * afterwards Apple notarization process can be started
Note: notarization of dmg or pkg lead to the same failure. See [2] for the full log w.r.t. pkg.
I hope this helps you to be able to reproduce the issue.
Thanks for your investigations!
-- Daniel
[1] https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d... <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle*L83__;Iw!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE03e0qq7A$> [2] https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904... <https://urldefense.com/v3/__https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs*2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w*2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh*2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX*2FN6zZoyz73I*3D__;JSUlJSU!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0bBsP8Hg$>
-- Kevin
[1] https://jdk.java.net/17 <https://urldefense.com/v3/__https://jdk.java.net/17__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0PgDN5dA$>
On 7/28/2021 8:27 AM, Daniel Peintner wrote: > All, > > I am trying to notarize an app (built with jpackage) for MacOS. > > jpackage at first *seems* to properly sign all resources with the available > --mac-sign options et cetera. > > Having said that, there are still remaining issues > 1. The app cannot be properly installed > (without hacks like xattr -d com.apple.quarantine /Applications/myAPP.app > ). > 2. I am also not able to properly notarize the app. > > According to online resources there seem to exist issues in *past* about > notarization but according to [1, 2] the issues are fixed. > > As mentioned, I still have issues :-( > Am I really the only one still having problems? > > Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without success) > > The issue seems to boil down to 2 errors (attached the error log from Apple > notarization process). > * app Folder > * libjli.dylib > > I thought I better ask first on the mailing list before creating an actual > bug report. > > Note1: I used to use the *old* javapackager that worked with the same > signature/credentials. > Note2: running jpackage without --mac-sign options causes many more errors > in notarization (Hence, jpackage signs most resources but fails with some) > > Any help / hint appreciated. > > Thanks, > > -- Daniel > > [1] https://bugs.openjdk.java.net/browse/JDK-8257488 <https://bugs.openjdk.java.net/browse/JDK-8257488> > [2] https://bugs.openjdk.java.net/browse/JDK-8251892 <https://bugs.openjdk.java.net/browse/JDK-8251892> > > > > ## APPLE LOG ## > > { > "logFormatVersion": 1, > "jobId": "...", > "status": "Invalid", > "statusSummary": "Archive contains critical validation errors", > "statusCode": 4000, > "archiveFilename": "myAPP-21.07.28.dmg", > "uploadDate": "2021-07-28T14:31:24Z", > "sha256": "...", > "ticketContents": null, > "issues": [ > { > "severity": "error", > "code": null, > "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP", > "message": "The signature of the binary is invalid.", > "docUrl": null, > "architecture": "x86_64" > }, > { > "severity": "error", > "code": null, > "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib", > "message": "The signature of the binary is invalid.", > "docUrl": null, > "architecture": "x86_64" > } > ] > }
OK - took me a while to see what you are doing. The problem is you are signing the pkg but building it from an unsigned app-image. If you are building in two phases (app-image, then installer package) you need the --mac-sign option on both phases. /Andy On 8/3/2021 10:37 AM, Andy Herrick wrote:
I was having problems notarizing anything yesterday, but fixed them today.
I can notarize my own test - but get failure when trying to notarize your app as built from non-modular branch of https://github.com/danielpeintner/Java11Test/
am looking into it ...
/Andy
On 8/2/2021 9:57 AM, Daniel Peintner wrote:
Hi Andy,
sorry - code looks for certificate key starting with: "Developer ID Application: " + <value of mac-signing-key-user-name> in order to not have to put full user name in. I missed that that with null user name that causes it to look for anything starting with "Developer ID Application: " (same thing with "Developer ID Installer: " for .pkg signing). And macos looks at the non-default keychains as well as the default ones when no keychain is specified.
Thanks for your feedback and yes in the simple case (with one certificate installed) it works without any further information.
May I ask you whether you were able to reproduce the issue?
Is there anything I can do to help?
Thanks,
-- Daniel
/Andy
On 7/29/2021 10:00 AM, Daniel Peintner wrote:
Hi Andy,
Since I don't know your setup I did not put anything there.
'--mac-sign' is enough to use the defaults in my setup.
It looks for the signing keys installed on my machine that start with "Developer ID Application " similar to '--mac-signing-key-user-name', 'Developer ID Application: ' etc.
If you want to test it you need to add your credentials which I do not know.
Hope this clarifies things,
-- Daniel
On Thu, Jul 29, 2021 at 3:29 PM Andy Herrick <andy.herrick@oracle.com <mailto:andy.herrick@oracle.com>> wrote:
The 'build.gradle' in this branch has --mac-signing-key-user-name commented out.
installerOptions += [ '--mac-sign', // '--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name', System.getenv('SIGNING_KEY_USER_NAME'), // '--mac-signing-keychain', System.getenv('SIGNING_KEYCHAIN_PATH') ]
clearly this cannot work, I assume you were just trying things ...
What is the full name of the certificate you intended to use, what keychain is it shown in "Keychain Access", and what are you normal values for your environment variables: 'SIGNING_KEY_USER_NAME' and 'SIGNING_KEYCHAIN_PATH' ?
/Andy
On 7/29/2021 4:36 AM, Daniel Peintner wrote:
Kevin, Andy,
Thanks for your quick response.
Full support for notarization in jpackage was added in JDK 17. Can you try an early access build of JDK 17 [1] and see if that works for you?
I did try JDK17-ea-32 also with the same result.
Since I do understand it is difficult reproduce the problem I put together a *very* simple test application which you can find in the "non-modular" branch here: https://github.com/danielpeintner/Java11Test/tree/non-modular <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/tree/non-modular__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE2ZACADEA$>
It is a gradle project. It uses Java 11 to run but in build.gradle on line#83[1] one can set the jpackage location (JDK17-ea-32 in this case).
The process is as follows * ./gradlew build * ./gradlew jpackage // creates the dmg/pkg in folder build/jpackage * afterwards Apple notarization process can be started
Note: notarization of dmg or pkg lead to the same failure. See [2] for the full log w.r.t. pkg.
I hope this helps you to be able to reproduce the issue.
Thanks for your investigations!
-- Daniel
[1] https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d... <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle*L83__;Iw!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE03e0qq7A$> [2] https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904... <https://urldefense.com/v3/__https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs*2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w*2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh*2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX*2FN6zZoyz73I*3D__;JSUlJSU!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0bBsP8Hg$>
-- Kevin
[1] https://jdk.java.net/17 <https://urldefense.com/v3/__https://jdk.java.net/17__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0PgDN5dA$>
On 7/28/2021 8:27 AM, Daniel Peintner wrote: > All, > > I am trying to notarize an app (built with jpackage) for MacOS. > > jpackage at first *seems* to properly sign all resources with the available > --mac-sign options et cetera. > > Having said that, there are still remaining issues > 1. The app cannot be properly installed > (without hacks like xattr -d com.apple.quarantine /Applications/myAPP.app > ). > 2. I am also not able to properly notarize the app. > > According to online resources there seem to exist issues in *past* about > notarization but according to [1, 2] the issues are fixed. > > As mentioned, I still have issues :-( > Am I really the only one still having problems? > > Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without success) > > The issue seems to boil down to 2 errors (attached the error log from Apple > notarization process). > * app Folder > * libjli.dylib > > I thought I better ask first on the mailing list before creating an actual > bug report. > > Note1: I used to use the *old* javapackager that worked with the same > signature/credentials. > Note2: running jpackage without --mac-sign options causes many more errors > in notarization (Hence, jpackage signs most resources but fails with some) > > Any help / hint appreciated. > > Thanks, > > -- Daniel > > [1] https://bugs.openjdk.java.net/browse/JDK-8257488 <https://bugs.openjdk.java.net/browse/JDK-8257488> > [2] https://bugs.openjdk.java.net/browse/JDK-8251892 <https://bugs.openjdk.java.net/browse/JDK-8251892> > > > > ## APPLE LOG ## > > { > "logFormatVersion": 1, > "jobId": "...", > "status": "Invalid", > "statusSummary": "Archive contains critical validation errors", > "statusCode": 4000, > "archiveFilename": "myAPP-21.07.28.dmg", > "uploadDate": "2021-07-28T14:31:24Z", > "sha256": "...", > "ticketContents": null, > "issues": [ > { > "severity": "error", > "code": null, > "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP", > "message": "The signature of the binary is invalid.", > "docUrl": null, > "architecture": "x86_64" > }, > { > "severity": "error", > "code": null, > "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib", > "message": "The signature of the binary is invalid.", > "docUrl": null, > "architecture": "x86_64" > } > ] > }
Hi Andy, The problem is you are signing the pkg but building it from an unsigned
app-image.
If you are building in two phases (app-image, then installer package) you need the --mac-sign option on both phases.
Thank you very much. It resolved the problem (I wasn't aware that --mac-sign option is required on both phases) I updated my test repo hoping it might be of use for others https://github.com/danielpeintner/Java11Test/tree/non-modular Thank you very much! -- Daniel
/Andy On 8/3/2021 10:37 AM, Andy Herrick wrote:
I was having problems notarizing anything yesterday, but fixed them today.
I can notarize my own test - but get failure when trying to notarize your app as built from non-modular branch of https://github.com/danielpeintner/Java11Test/
am looking into it ...
/Andy
On 8/2/2021 9:57 AM, Daniel Peintner wrote:
Hi Andy,
sorry - code looks for certificate key starting with: "Developer ID Application: " + <value of mac-signing-key-user-name> in order to not have to put full user name in. I missed that that with null user name that causes it to look for anything starting with "Developer ID Application: " (same thing with "Developer ID Installer: " for .pkg signing). And macos looks at the non-default keychains as well as the default ones when no keychain is specified.
Thanks for your feedback and yes in the simple case (with one certificate installed) it works without any further information.
May I ask you whether you were able to reproduce the issue?
Is there anything I can do to help?
Thanks,
-- Daniel
/Andy On 7/29/2021 10:00 AM, Daniel Peintner wrote:
Hi Andy,
Since I don't know your setup I did not put anything there.
'--mac-sign' is enough to use the defaults in my setup.
It looks for the signing keys installed on my machine that start with "Developer ID Application " similar to '--mac-signing-key-user-name', 'Developer ID Application: ' etc.
If you want to test it you need to add your credentials which I do not know.
Hope this clarifies things,
-- Daniel
On Thu, Jul 29, 2021 at 3:29 PM Andy Herrick <andy.herrick@oracle.com> wrote:
The 'build.gradle' in this branch has --mac-signing-key-user-name commented out.
installerOptions += [ '--mac-sign', // '--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name', System.getenv('SIGNING_KEY_USER_NAME'), // '--mac-signing-keychain', System.getenv('SIGNING_KEYCHAIN_PATH') ]
clearly this cannot work, I assume you were just trying things ...
What is the full name of the certificate you intended to use, what keychain is it shown in "Keychain Access", and what are you normal values for your environment variables: 'SIGNING_KEY_USER_NAME' and 'SIGNING_KEYCHAIN_PATH' ?
/Andy On 7/29/2021 4:36 AM, Daniel Peintner wrote:
Kevin, Andy,
Thanks for your quick response.
Full support for notarization in jpackage was added in JDK 17. Can you
try an early access build of JDK 17 [1] and see if that works for you?
I did try JDK17-ea-32 also with the same result.
Since I do understand it is difficult reproduce the problem I put together a *very* simple test application which you can find in the "non-modular" branch here: https://github.com/danielpeintner/Java11Test/tree/non-modular <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/tree/non-modular__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE2ZACADEA$>
It is a gradle project. It uses Java 11 to run but in build.gradle on line#83 [1] one can set the jpackage location (JDK17-ea-32 in this case).
The process is as follows * ./gradlew build * ./gradlew jpackage // creates the dmg/pkg in folder build/jpackage * afterwards Apple notarization process can be started
Note: notarization of dmg or pkg lead to the same failure. See [2] for the full log w.r.t. pkg.
I hope this helps you to be able to reproduce the issue.
Thanks for your investigations!
-- Daniel
[1] https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d... <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle*L83__;Iw!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE03e0qq7A$> [2] https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904... <https://urldefense.com/v3/__https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs*2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w*2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh*2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX*2FN6zZoyz73I*3D__;JSUlJSU!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0bBsP8Hg$>
-- Kevin
[1] https://jdk.java.net/17 <https://urldefense.com/v3/__https://jdk.java.net/17__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0PgDN5dA$>
On 7/28/2021 8:27 AM, Daniel Peintner wrote:
All,
I am trying to notarize an app (built with jpackage) for MacOS.
jpackage at first *seems* to properly sign all resources with the available --mac-sign options et cetera.
Having said that, there are still remaining issues 1. The app cannot be properly installed (without hacks like xattr -d com.apple.quarantine /Applications/myAPP.app ). 2. I am also not able to properly notarize the app.
According to online resources there seem to exist issues in *past* about notarization but according to [1, 2] the issues are fixed.
As mentioned, I still have issues :-( Am I really the only one still having problems?
Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without success)
The issue seems to boil down to 2 errors (attached the error log from Apple notarization process). * app Folder * libjli.dylib
I thought I better ask first on the mailing list before creating an actual bug report.
Note1: I used to use the *old* javapackager that worked with the same signature/credentials. Note2: running jpackage without --mac-sign options causes many more errors in notarization (Hence, jpackage signs most resources but fails with some)
Any help / hint appreciated.
Thanks,
-- Daniel
[1] https://bugs.openjdk.java.net/browse/JDK-8257488 [2] https://bugs.openjdk.java.net/browse/JDK-8251892
## APPLE LOG ##
{ "logFormatVersion": 1, "jobId": "...", "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "archiveFilename": "myAPP-21.07.28.dmg", "uploadDate": "2021-07-28T14:31:24Z", "sha256": "...", "ticketContents": null, "issues": [ { "severity": "error", "code": null, "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" }, { "severity": "error", "code": null, "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" } ] }
Not really enough info given here to act on. Exactly what java version/build are you using? As Kevin suggested it best to try JDK17 EA first, but I can notarize simple test app with JDK16 , staple the notarization, and then download it and run it on other machines without the quarantine hacks. While implementing support for the Mac App Store in JDK17, we had to change the way signing works (we now unsign the java runtime and then re-sign it's components together with the app's components, where we previously used the signing already present in the released jdk.) For this reason I think it is better to look only at problem that persist in JDK17 at this time. /Andy On 7/28/2021 11:27 AM, Daniel Peintner wrote:
All,
I am trying to notarize an app (built with jpackage) for MacOS.
jpackage at first *seems* to properly sign all resources with the available --mac-sign options et cetera.
Having said that, there are still remaining issues 1. The app cannot be properly installed (without hacks like xattr -d com.apple.quarantine /Applications/myAPP.app ). This indicates the app is not notarized or the notarization is not properly stapled. 2. I am also not able to properly notarize the app.
According to online resources there seem to exist issues in *past* about notarization but according to [1, 2] the issues are fixed.
As mentioned, I still have issues :-( Am I really the only one still having problems?
Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without success)
The issue seems to boil down to 2 errors (attached the error log from Apple notarization process). * app Folder * libjli.dylib
From below it looks like you are trying to sign a dmg. Notarization or a jpackage artifact requires either a signed pkg or a zipped signed app image. It looks like notarizing a signed dmg is now supported by Apple, but this is not something that was available when we initially implemented this in jpackage. Can you try the same thing with a "pkg" instead of a "dmg". We will have to look into what is needed to sign "dmg" artifacts now. /Andy
participants (3)
-
Andy Herrick
-
Daniel Peintner
-
Kevin Rushforth