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

Michael Hall mik3hall at gmail.com
Sat May 3 15:49:58 UTC 2025



> On May 3, 2025, at 10:33 AM, Christoph <duke at openjdk.org> wrote:
> 
> 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:

Not for me with 

${PACKAGER} \
	--verbose \
	--jlink-options '--strip-debug --no-man-pages --no-header-files' \
	--input input \
	--icon GenericApp.icns \
	--resource-dir resources \
	--name HalfPipe \
	--type "dmg" \
	--main-jar halfpipe.jar \
	--main-class us.hall.hp.common.LoaderLaunchStub \
	--module-path '/Users/mjh/Documents/javafx-jmods-21.0.1:mods' \
 	--add-modules javafx.swing,javafx.graphics,javafx.controls,us.hall.eio,org.openjdk.nashorn,java.compiler,java.desktop,java.logging,java.management,jdk.management.agent,java.prefs,java.se,java.rmi,java.scripting,java.sql,java.xml,jdk.attach,jdk.jshell,jdk.crypto.ec,jdk.jdeps,jdk.jcmd,jdk.zipfs,jdk.jfr \
	--java-options '-Xmx1024m -XX:+UnlockDiagnosticVMOptions --add-opens java.desktop/javax.swing.text=ALL-UNNAMED --enable-preview -Djdk.attach.allowAttachSelf=true -XX:+UseG1GC -XX:MaxGCPauseMillis=50 --enable-native-access=ALL-UNNAMED -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider --add-opens=java.base/java.lang=ALL-UNNAMED --add-exports java.base/java.lang=ALL-UNNAMED --add-exports org.openjdk.nashorn/org.openjdk.nashorn.tools=ALL-UNNAMED -Dapp.path=$APPDIR -Djava.security.policy=$APPDIR/all.policy -Dapple.laf.useScreenMenuBar=true -Dapple.awt.application.name=HalfPipe -Dconsole=pane' \
	--mac-package-identifier "us.hall.HalfPipe" \
	--mac-sign \
	--mac-signing-key-user-name "$SIGNING_CERT" \
	--mac-entitlements "entitlements.xml" \
	--mac-dmg-content additional/src.zip,additional/Half-Pipe.pdf

All I see are the 

[10:05:03.044] Running /usr/bin/codesign


> 
> 
> 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).

Hardened runtime sounds sort of familiar, it’s been a while. Other requirements might of changed.



More information about the core-libs-dev mailing list