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.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" >>>> > } >>>> > ] >>>> > } >>>> >>>>
