“codesign”

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

I’m not sure why you’re having problems with this. Lemme walk you through how I tested this today. You can review my steps to see if there’s anything obviously different. And if there isn’t, you can run through the steps yourself to see if you can repeat my experience. If so, you can then compare your primary daemon to your test daemon to see what’s different. So, here’s what I did: Using Xcode 16.4 on macOS 15.5, I created a new project from the macOS > App template. I set it up as a daemon per the advice in Signing a daemon with a restricted entitlement. Note that the details will differ a bit but the final result will be the same. Specifically, here’s my final structure: % find Test791996.app Test791996.app Test791996.app/Contents Test791996.app/Contents/_CodeSignature Test791996.app/Contents/_CodeSignature/CodeResources Test791996.app/Contents/MacOS Test791996.app/Contents/MacOS/Test791996 Test791996.app/Contents/embedded.provisionprofile Test791996.app/Contents/Info.plist Test791996.app/Contents/PkgIn

[quote='793977021, neil218, /thread/793977, /profile/neil218'] I attempted to codesign my native dynamic library (.dylib) with an entitlement [/quote] That won’t work. Entitlements are only relevant to a main executable. If you sign library code with an entitlement it is, at best, ignored. Creating distribution-signed code for macOS has general guidelines for signing Mac code and it specifically calls this out. Expanding on this a little, when a process runs an executable, the system checks the entitlements claimed by that executable. If all the entitlements are authorised by the executable’s profile [1], the process starts running that program and gains those entitlements. If not, the system kills the process [2]. So, to get this to work you have to change how you sign your app as a whole. This can be tricky. I usually recommend that Java developers start Java by way of a native trampoline. See the info and links in the TCC and Main Executables section of On File System Permissions. However, that tr

[quote='793731021, VarunC, /thread/793731, /profile/VarunC'] If I try to sign my obs app generated in second step codesign --deep [/quote] Don’t use --deep when signing code. See --deep Considered Harmful for an explanation as to why that’s bad. I can’t really help you with third-party tools like CMake. However, we have solid documentation that explains how to sign and package Mac code outstide of Xcode, namely: Creating distribution-signed code for macOS Packaging Mac software for distribution I recommend that you read that, apply the steps manually, verify that things are working, and then research how to integrate equivalent steps into yoru third-party tools. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The recipe to transfer the Developer ID Certs --> MyCertificates isn't perfect....it did allow me to copy the Certs into login / MyCertificates, but if I then try to delete the Developer ID Certs associated with System / Certificates, the delete command deletes BOTH copies of the Cert, leaving me with nothing. The good news is that codesign accepts the Certs I transferred by .p12 file Export / Import onto my M2 computer (which was the higher-level problem). It only gives a warning about finding multiple copies of the same cert. I chose NOT to accept the answer because it leaves the codesign with this warning.