Hi Quinn,
Thank you for your answer.
I will try bundling each auxiliary binary but this may imply making the macOS version quite different from the versions for other platforms, something I hoped I could avoid.
A remaining couple of questions:
1- when myMainApp calls myAuxBin shall it be through a Finder command "open" or can I still use a direct call to the binary within the MacOS folder ?
2- One of these auxiliary binary uses a classical Open dialogue to open a file but also opens with no dialogue a set of other files with the same name but different extensions. Is this compatible with sandboxing or is there a trick I should know ?
All the best
Linus
Post
Replies
Boosts
Views
Activity
I forgot to mention the solution I finally found.
I codesign and harden the auxiliary binaries prior adding them to Xcode.
In Xcode I do the following:
Product/Archive
Distribute App
Developer ID
Upload
Distribution certificate: select "Developer ID application..."
Upload
Close
wait for Apple's notification
Click button "Export Notarized App"
I reply to myself.
Transporter's error message "Failed to decompress the app." with no more explanation is just a shame and was responsible for a big waste of time on my side.
Another problem is that command line test tools such as
spctl --assess or spctl -a -t execute
may give inaccurate results depending on the certificate is use (Developer ID or Apple Distribution)
After a lot of efforts, it turned out that: one of the 226 libraries of my App had a missing LCUUID
one of the libs had a problem with a sealed ressource. I had to search for it manually to finally identify the problem.
In other words "Transporter: Failed to decompress the app." should translate into "Transporter successfully decompress the App, but the bundle is rejected because ..."_
I have not tested it yet but I read that the problem is "productsign" not "Transporter.app".
productsign is Okay with Catalina but does not correctly sign .pkg files with Big Sur.
If this is the correct answer, I would say that the error message from Transporter is totally non-informative and misleading.
I finally found a solution to obtain a notarised application which is functional.The bundle is organised as follows TestApp.app Contents MacOS testAppp <-- a launcher (C binary) myAlert <-- an alert dialogue (Cocoa binary) Resources winteracter <-- an X11 (Xquartz) window and dialogue (Fortran binary)The binary "winteracter" is based on the Winteracter library <http://www.winteracter.com> which uses OpenMotif and Xquartzwinteracter binaryThis binary is hardened manually (i.e. from outside Xcode) prior to the otherscodesign -d --force --options runtime --verbose=4 -s "$DEV_CERTIFICATE" --entitlements "winteracter.entitlements" "winteracter" winteracter.entitlements should only contain the following:com.apple.security.cs.disable-library-validation
testApp and myAlert binariesThese are signed and hardened either manuallycodesign -d --force --options runtime --verbose=4 -s "$DEV_CERTIFICATE" "$MYBINARY"or using Xcode In that case be sure to manually erase the field "Code Signing Entitlements" en Build Settings. It may remained filled in even if you delete "Sandboxing" from the the Capabilities interface.Once notarized the application is functional.I tried sandboxing it but the infamous error "mapping process and mapped file (non-platform) have different Team IDs" went back !But what were my mistakes?1- Apple says that sandboxing keys must appear only once in entitlement file of the main binary, with other having only the "inherit" key. I wrongly assumed that com.apple.security.cs.disable-library-validation was inherited too.2- I thought the key com.apple.security.app-sandbox was compulsory in entitlement files. Not at all!3- I wrongly assumed that setting com.apple.security.app-sandbox to false is equivalent as no entitlement file. Wrong again!4- I wrongly assumed that the Xcode interface "Signing & Capabilities" correctly manages the Build Settings5- I performed so many trial an errors that I do not remember all by all dead ends where I got lost.
I am using 10.14.5 since my Catalina is quarantined at work.My application is X11 based and Xquartz 2.7.11 is installed.The application was successfully notarized and stapled using Xcode and the option "Disable library validation" checked.I also tried the command line approach with codesign, altool and xcrun stapler.Whatever I do the application fails with error:/opt/X11/lib/libXinerama.1.dylib: code signature in (/opt/X11/lib/libXinerama.1.dylib) not valid for use in process using Library Validation: mapping process and mapped file (non-platform) have different Team IDsYes the Team IDs are different: myApplication --> TeamIdentifier=P65398CN49 libXinerama.1.dylib --> TeamIdentifier=NA574AWV7Ebut the hardening option "Disable library validation" being checked I do not understand that error message.Clearly, this key does not work as described by Apple (see below).com.apple.security.cs.disable-library-validationTypically, the Hardened Runtime’s library validation prevents an app from loading frameworks, plug-ins, or libraries unless they’re either signed by Apple or signed with the same team ID as the app. The macOS dynamic linker (dyld) provides a detailed error message when this happens. Use the Disable Library Validation Entitlement to circumvent this restriction.I searched the internet but could not find any solution.