Thomas Neidhart

I have worked on some bytecode manipulation library that would be able to do that: - read the jmod - replace the dylib with signed version - update hashes in...

Do you have a trace of a x64 build that is getting signed and notarized fine so I can check the notarization log? Maybe we should check if the x64...

I cant access the notarization build to retrieve the uuid. However, I downloaded the artifact that succeeded, extracted all files from the jmods and compared them to the dylib's in...

the aarch64 build has 14:08:38 BUILD_CONFIG[MAKE_EXPLODED]="true" while the x86 has 14:06:28 BUILD_CONFIG[MAKE_EXPLODED]="false" that seems to change the build quite a lot from the logs.

Could it be that aarch64 is built with a different Xcode (12.4) compared to x86 which has a different default settings to the code signing identity that is being used?...

The building.md in the jdk project says something about that: https://github.com/adoptium/jdk21u/blob/7d0a937446d37ef2cd88ebf91b3a429134d447a0/doc/building.md?plain=1#L905

When search for codesigning in the jdk repo, I found a variable MACOSX_CODESIGN_MODE https://github.com/search?q=repo%3Aadoptium%2Fjdk%20MACOSX_CODESIGN_MODE&type=code The build was switched to use the Eclipse Signing Service instead of doing code signing by...

``` checking for macosx code signing mode... auto, default 15:20:24 checking for macosx code signing identity... openjdk_codesign, default 15:20:24 checking if codesign with hardened runtime is possible... no 15:20:24 checking...

for whatever reasons these lines are missing for the x86 build, while they are there for the aarch64 build. So it looks like in case of aarch64 a debug codesigning...

I would have no clue how to fix that right away. I wonder which timestamp is used for the final nightly artifacts? Is this the timestamp when the release is...