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.herr...@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/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle#L83 > <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/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs%2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w%2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh%2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX%2FN6zZoyz73I%3D > <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" >> > } >> > ] >> > } >> >>