RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions

[Christoph]

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at 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