Thomas Neidhart

so it looks like 1 file in the archive is not signed and has no secure timestamp? Contents/Payload/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/jmods/jdk.jdwp.agent.jmod/lib/libdt_socket.dylib

From the build script I see that you first use the code signing api at https://cbi.eclipse.org/macos/codesign/sign to sign the file and then notarize the archive. Maybe something in the signing...

In the error logs of the codesign service I dont find anything related to the libdt_socket.dylib file. The access logs dont indicate the file to be signed.

This line selects all dylib with certain permissions to be setup for signing: ``` FILES=$(find "${TMP_DIR}" -perm +111 -type f -not -name '.*' -o -name '*.dylib' || find "${TMP_DIR}" -perm...

I could see the request in the access log, and there was no error during signing. I could retrieve the full log when using notarytool to notarize the package: ```...

so its not only a single file but many, but all of them are inside jmods. Could it be that the dylibs that are packaged in the jmods have not...

``` if [[ "${BUILD_CONFIG[ASSEMBLE_EXPLODED_IMAGE]}" == "true" ]]; then # This is required so that make will only touch the jmods and not re-compile them after signing FULL_MAKE_COMMAND="make -t \&\& ${FULL_MAKE_COMMAND}"...

I have a bit of a crazy idea, but I tested it and seemed to work fine. In the sign.sh script, we extract the archive and sign all encountered dylib...

One could also quite easily write something in java to replace a file inside a jmod to avoid using proguard. Was using this to illustrate that it would be possible...

hmm the jmods will need to be post-processed as the hashes change and the module-info.class inside them will not match anymore. Running jmod hash might help though.