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