On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almat...@openjdk.org> wrote:
> - It is not clear on which macOS versions codesign fails if application > bundle contains additional content. > - As a result test was modified to generate only application image, since PKG > or DMG cannot be generated if signing fails. Exit code of jpackage is > ignored, but generated application image will be checked for additional > content. > - This change is for macOS only. > - Previous implementation of test (forcing expected exist code to 1) was not > doing anything useful, since we never checked if additional content was > copied or not. Jpackage does include the options as well from the logs: 2025-05-02T17:19:25.6907840Z [17:19:12.379] Preparing Info.plist: /Users/runner/work/***/***/jabgui/build/distribution/JabRef.app/Contents/Info.plist. 2025-05-02T17:19:25.6908750Z [17:19:12.383] Using custom package resource [Application Info.plist] (loaded from Info.plist). 2025-05-02T17:19:25.6909590Z [17:19:12.388] Using custom package resource [Java Runtime Info.plist] (loaded from Runtime-Info.plist). 2025-05-02T17:19:25.6910240Z [17:19:23.350] Running /usr/bin/codesign 2025-05-02T17:19:25.6910740Z [17:19:24.530] Command [PID: 6752]: 2025-05-02T17:19:25.6911920Z /usr/bin/codesign -s Developer ID Application: JabRef e.V. (6792V39SK3) -vvvv --timestamp --options runtime --prefix org.*** --entitlements buildres/mac/***.entitlements --force build/distribution/JabRef.app/Contents/runtime 2025-05-02T17:19:25.6912950Z [17:19:24.530] Output: 2025-05-02T17:19:25.6914200Z build/distribution/JabRef.app/Contents/runtime: replacing existing signature 2025-05-02T17:19:25.6915140Z build/distribution/JabRef.app/Contents/runtime: signed bundle with Mach-O thin (arm64) [com.oracle.java.JabRef] 2025-05-02T17:19:25.6915990Z [17:19:24.530] Returned: 0 2025-05-02T17:19:25.6916510Z [17:19:24.530] Running /usr/bin/codesign 2025-05-02T17:19:25.6917100Z [17:19:25.655] Command [PID: 6759]: 2025-05-02T17:19:25.6918000Z /usr/bin/codesign -s Developer ID Application: JabRef e.V. (6792V39SK3) -vvvv --timestamp --options runtime --prefix org.*** --entitlements buildres/mac/***.entitlements --force build/distribution/JabRef.app 2025-05-02T17:19:25.6918880Z [17:19:25.656] Output: 2025-05-02T17:19:25.6919430Z build/distribution/JabRef.app: replacing existing signature 2025-05-02T17:19:25.6920230Z build/distribution/JabRef.app: signed app bundle with Mach-O thin (arm64) [org.***JabRef] 2025-05-02T17:19:25.6920880Z [17:19:25.656] Returned: 0 2025-05-02T17:19:25.6921160Z 2025-05-02T17:19:25.6921510Z [17:19:25.656] Succeeded in building Mac Application Image package 2025-05-02T17:19:36.0557030Z Warning: Support for per-user configuration of the installed application will not be supported due to missing "build/distribution/JabRef.app/Contents/app/.package" in predefined signed application image. After creating the app image we put additional content in it under Resources. That probably affects the integrity? of the whole stuff **Runtime** options is for Hardened Runtime https://developer.apple.com/documentation/security/hardened-runtime which allows specifying exclusions like jit in the entitlements **Timestamp** is also required https://developer.apple.com/documentation/security/resolving-common-notarization-issues#Include-a-secure-timestamp Otherwise, notarization fails with no timestamp or invalid timestamp. **Deep** is like going recursively through the files. But should be avoided. I will try without as well To upload a macOS app to be notarized, you must enable the Hardened Runtime capability. For more information about notarization, see [Notarizing macOS software before distribution](https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution). ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848675876
