codesign

This was never resolved properly. My Developer ID Certificates exist in two places within KeychainAccess: (correct) from login in MyCerticates (incorrect) from system in Certificates I tried to clean this up, but found that from the GUI, when you say to delete the Certificate in the incorrect location, it also deletes the one in the correct location. I accepted the status quo (2 copies of Certificate). The Codesign tool (embedded within the jpackage script) gives a warning two copies found of the certificate, choosing to use the fist one. Because of that failsafe feature, I was able to complete all my codesigning. With that, this thread is closed.

POSSIBLE CLUE: This feedback from: codesign --display --verbose=2 indicates a valid Developer ID signature is attached, (not an adhoc signature) pierrebierre@Pierres-iMac ~ % codesign --display --verbose=2 ~/DFG2D_MacOS_Manufacturing/JogAmpSignedJar/jogamp-fat/natives/macosx-universal/libnewt_head.dylib Executable=/Users/pierrebierre/DFG2D_MacOS_Manufacturing/JogAmpSignedJar/jogamp-fat/natives/macosx-universal/libnewt_head.dylib Identifier=libnewt_head Format=Mach-O universal (x86_64 arm64) CodeDirectory v=20400 size=912 flags=0x0(none) hashes=23+2 location=embedded Signature size=9047 Authority=Developer ID Application: Pierre Bierre (SL7L4YU8GT) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Aug 4, 2025 at 11:36:17 AM Info.plist=not bound TeamIdentifier=SL7L4YU8GT Sealed Resources=none Internal requirements count=1 size=172 The codesign --verify --verbose command gives: pierrebierre@Pierres-iMac ~ % codesign --verify --verbose ~/DFG2D_Mac

I have a valid Developer ID certificate and key. When I codesign, I'm prompted to enter my system pw. codesign gives absolutely ZERO feedback that it isn't using the Developer ID I reference in the codesign command line. It just says it's signed in response to --verify. You haven't told me anything specifically actionable, like how would I verify during code signing that it's using my Developer ID vs. adhoc. Is there a way to tell, short of the long, exasperating feedback loop leading to Notarization testing?

The immediate cause of your problem is you have code that’s not signed: % file /Volumes/DataflowGeometry2D/DataflowGeometry2D.app/Contents/app/DFG2D_Mac_x86_313.jar /Volumes/DataflowGeometry2D/DataflowGeometry2D.app/Contents/app/DFG2D_Mac_x86_313.jar: Java archive data (JAR) % mkdir DFG2D_Mac_x86_313 % cd DFG2D_Mac_x86_313 % unzip /Volumes/DataflowGeometry2D/DataflowGeometry2D.app/Contents/app/DFG2D_Mac_x86_313.jar Archive: /Volumes/DataflowGeometry2D/DataflowGeometry2D.app/Contents/app/DFG2D_Mac_x86_313.jar … inflating: lib/jogamp-fat/jogamp-fat.jar … % mkdir jogamp-fat % cd jogamp-fat % unzip ../lib/jogamp-fat/jogamp-fat.jar Archive: ../lib/jogamp-fat/jogamp-fat.jar … inflating: natives/macosx-universal/libjocl.dylib … % file natives/macosx-universal/libjocl.dylib natives/macosx-universal/libjocl.dylib: Mach-O universal binary with 2 architectures… … % codesign -d -vvv natives/macosx-universal/libjocl.dylib … CodeDirectory v=20400 size=1606 flags=0x20002(adhoc,linker-signed) … … The notary service

My latest process is still failing Notarization, saying 10 .dylib files (located in the jog amp MacosX Universal Binaries folder) are unsigned. My process: Unarchive jogamp-fat.jar (command line too jar xf) codesign --timestamp all 10 .dylib files confirm all signed reJar the jog amp-fat.jar codesign the jar, and confirm signed add signed jar back into Eclipse Java project as an external library Export app jar use jpackage tool to sign app jar , build .dmg, and sign that test run install and launch submit .dmg to Notarization Will try to email the .dmg to Quinn

I have played around a bit more with the code: I tried passing pointers to the functions themselves Making sure the callbacks are called from the mainthread But nothing seems to work. I did stumble into this page though https://developer.apple.com/documentation/xcode/investigating-memory-access-crashes#Use-VM-Region-Info-to-locate-the-memory-in-your-apps-address-space And it's useful to understand the crash logs. My full crash is: Exception Type: EXC_BAD_ACCESS (SIGKILL) Exception Subtype: KERN_PROTECTION_FAILURE at 0x0000000000000000 Exception Codes: 0x0000000000000002, 0x0000000000000000 VM Region Info: 0 is not in any region. Bytes before following region: 4307271680 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 100bbc000-100bc0000 [ 16K] r-x/r-x SM=COW /var/containers/Bundle/Application/D7CA13B9-71D1-467E-882D-317F9AF57049/OpacityPod_Example.app/OpacityPod_Example Termination Reason: CODESIGNING 2 Invalid Page So it's clearly a pointer exceptio

[quote='850703022, tomdesantis, /thread/794080?answerId=850703022#850703022, /profile/tomdesantis'] Surprisingly in my notary log it seems that all the Mach-O images are in the log. [/quote] Right. I suspect that my notarisation of your app has perturbed the system in some way. Given that, I’d like to try to get us back into the state where things are failing. Unfortunately that means that I have to get you to do some more work )-: Specifically: Rebuild and re-sign your app. Check that the top-level app has a different cdhash, that is, this command outputs something different: % codesign -d -vvv HotelOrganizer.app … CDHash=b4563a07ac6827cced5dd13a172c41c80ca7d589 … Notarise that. Grab the notary log and save that away. Staple and package the app. Reproduce the problem. Attach the new copy of your app and the notary log from step 4 to your bug report. Reply back here when you’re done and I’ll take another look. [quote='850703022, tomdesantis, /thread/794080?answerId=850703022#850703022, /profile/tomde

Every good debugging story starts with a “Huh, that’s weird.”, and this is no exception (-: Consider this: % stapler validate -v HotelOrganizer.app … Downloaded ticket has been stored at file:///var/folders/n_/p9vcphfj2l7c7fmh0ct2f70w0000gp/T/4985875e-0770-4d79-8ec1-14c034783d98.ticket. The validate action worked! So far so good. But now look at this: % NotarizationTicketDump /var/folders/n_/p9vcphfj2l7c7fmh0ct2f70w0000gp/T/4985875e-0770-4d79-8ec1-14c034783d98.ticket b4563a07ac6827cced5dd13a172c41c80ca7d589 Note NotarizationTicketDump is a tool I wrote myself to dump the cdhashes in a ticket. I can’t share that tool but you, as the person who did the notarisation, can get the same information from the notarisation log. More on this below. The ticket has only one cdhash value. That value matches your main app: % codesign -d -vvv HotelOrganizer.app … CDHash=b4563a07ac6827cced5dd13a172c41c80ca7d589 … which is good, but your app contains a lot of other Mach-O images [1]: % FindMachO.sh HotelOrganizer.app

Sharing the full email I sent to Apple Support I am consistently encountering the ITMS-90207 error Invalid Bundle. The bundle at 'Runner.app' does not contain a bundle executable. when attempting to upload my Flutter iOS app to App Store Connect via both Transporter and direct upload from Xcode Organizer. This issue persists despite extensive troubleshooting and thorough local validation, which shows the IPA is correctly formed. App Details: App Name: OnOn App Store Connect App ID: 6502598657 Bundle Identifier: com.onon.app Latest Version/Build Attempted: Version 1.0.24, Build 50 Error Details: Exact Error Message: Invalid Bundle. The bundle at 'Runner.app' does not contain a bundle executable. (ID: [e.g., f548c384-73e9-4f09-96a0-363b7d67f650 from your log]) Transporter Log Reference: From my Transporter logs, the specific iris-code is STATE_ERROR.VALIDATION_ERROR. Example Build ID from Transporter Log: [e.g., 6bd99937-1283-486e-a245-419ea29443f0] (This ID might vary with each attempt, but providing a recent

I used syspolicy_check and this is the message I got: App has failed one or more pre-distribution checks. Codesign Error File: HotelOrganizer.app Severity: Fatal Full Error: Gatekeeper rejected this file. If there isn't a more descriptive error elsewhere in this output, please file a Feedback through Feedback Assistant.app so we can continue to improve syspolicy_check. Please include the app bundle you are checking and a sysdiagnose taken immediately after running syspolicy_check. Type: Notary Error I'm really frustrated by this, I tried everything I could find in the forum. I cannot distribute my app to my customers because of this issue.

No, I haven't added that. Is it possible that maybe this library entitlement is added automatically during codesigning? Actually after further testing, I realized that the culprit seem to be the entitlements I assign to the node and Chromium Helper executables within the Playwright framework ( com.apple.security.cs.allow-jit and com.apple.security.cs.allow-unsigned-executable-memory ). The JIT entitlement applied to the main python executable does not affect gatekeeper.