[External] : Re: jpackage MacOS Notarization
Andy Herrick
andy.herrick at oracle.com
Thu Jul 29 15:58:09 UTC 2021
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 at oracle.com
> <mailto:andy.herrick at 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
>> <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"
>> > }
>> > ]
>> > }
>>
More information about the core-libs-dev
mailing list