I am trying to modify an existing bundle so that I can notarize it. Here its organisation: graps.app Contents MacOS prelaunch <-- main applauncher grasp <-- auxiliary binary calling the libraries Here the original DYLD_LIBRARY_PATH: DYLD_LIBRARY_PATH="." DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:/Applications/MATLAB/MATLAB_Runtime/v911/runtime/maci64" DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:/Applications/MATLAB/MATLAB_Runtime/v911/bin/maci64" DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:/Applications/MATLAB/MATLAB_Runtime/v911/sys/os/maci64" export DYLD_LIBRARY_PATH and the RPATHs that mimic it: install_name_tool -add_rpath "/." grasp install_name_tool -add_rpath "/Applications/MATLAB/MATLAB_Runtime/v911/bin/maci64" grasp install_name_tool -add_rpath "/Applications/MATLAB/MATLAB_Runtime/v911/runtime/maci64" grasp install_name_tool -add_rpath "/Applications/MATLAB/MATLAB_Runtime/v911/sys/os/maci64" grasp install_name_tool -add_rpath "/Applications/MATLAB/MATLAB_Runtime/v911/extern/bin/maci64" grasp Note that it is not enough to add RPATHs to the auxiliary binary "grasp". They must also be added to the main binary "prelaunch". But why ? 1- Unsigned application using DYLD_LIBRARY_PATH set RPATHs set DYLD_LIBRARY_PATH not set DYLD_PRINT_LIBRARIES ### App running ### 2- Unsigned application with lib tracking set RPATHs set DYLD_LIBRARY_PATH set DYLD_PRINT_LIBRARIES ### App hangs after loading 894 libraries (MatLab has more than 3000 libs and uses many macOS libs) ### The terminal output is a total of 119594 characters. ### Is this more than allowed by `DYLD_PRINT_LIBRARIES`? ### As a consequence the check cannot be completed. Too bad !!! 3- Unsigned application using RPATHs set RPATHs not set DYLD_LIBRARY_PATH set or not DYLD_PRINT_LIBRARIES ### Error: Could not find version 9.11 of the MATLAB Runtime. ### Attempting to load libmwmclmcrrt.9.11.dylib. <-- it does not say "not found"! 307 libs are loaded before this error message occurs 59 are MatLab libs all from /bin/maci64 but the following one is from /runtime/maci64 libmwmclmcrrt.9.11.dylib is the 13th lib loaded and the 6th MatLab one: dyld: loaded: <11D060E5-13C3-34EE-96C9-A7EA2A7E34B3> /Applications/MATLAB/MATLAB_Runtime/v911/runtime/maci64/libmwmclmcrrt.9.11.dylib Note that MacOS does not say "not found" Thus RPATH does not seem to behave exactly as DYLD_LIBRARY_PATH did but why? How can "ignoring DYLD_LIBRARY_PATH" break a library loading ? How can I debug this ? This is very disappointing since, otherwise, the application would easily sign and notarize. I have exhausted all the tracks I knew and found on the internet. Alain

My application contains a binary which calls a shell script located in the "Resources" folder through the command: open -b com.apple.terminal '../Resources/myScript.sh' which opens the script in a Terminal window. This works on a M1 computer and on Intel macOS prior to Ventura. On an Intel Mac upgraded to Ventura 13.2 I get the error message: "myscript.sh" can’t be opened because (null) is not allowed to open documents in Terminal. Adding the entitlement <com.apple.security.automation.apple-events> had no effect. Since this works on macOS other than Ventura for Intel I don't see which hardening key or whatsoever is missing. What can I do to get rid of that error ? All the best

Am I right to say that all binaries in a notarised bundle must have the minimum OS version set ? If yes, I understood that this can be either through "LC_VERSION_MIN_MACOSX" or "minos" as reported by "tool -l" With Intel's Fortran compiler (idem for gFortran): XE Composer fort has a "-mmacos-version-min" option which sets the "LC_VERSION_MIN_MACOSX" key OneApi Intel ifort has none but sets the "minos" and "sdk" keys My problem is that binaries coming from the build server of our IT exhibit none of these keys. I don't know why and how to change that. The binaries without the above keys can be launched through the Open contextual menu. However, once signed they NO LONGER work and give : Killed: 9 logout Those having the "LC_VERSION_MIN_MACOSX" key work as expected. Are these binaries compatible with notarisation nevertheless? Is there a way to add "minos" and "sdk" keys afterwards? All the best and happy new year !

The bundle of my App contains a main binary "myMainBin" and an auxiliary binaries "myAuxBin". myMainBin has the entitlement "com.apple.security.files.user-selected.read-write" and successfully read files. plist version="1.0" dict keycom.apple.security.app-sandbox/key true/ keycom.apple.security.files.user-selected.read-write/key true/ /dict /plist myAuxBin has the following entitlements plist version="1.0" dict keycom.apple.security.app-sandbox/key true/ keycom.apple.security.inherit/key true/ /dict /plist Once launched by myMainBin, myAuxBin has its own window and menubar Despite of the "inherit" entitlement, its Open dialogue fails opening files with the console message: Sandbox: takin(5019) deny(1) file-read-xattr /Users/xxxxx/yyyy/myDataFile.data But Why ? How can I solve this problem ? Another strange point If the bundle is NOT sandboxed, myAuxBin inherits the icon of the bundle (shown in the dock). If the bundle IS sandboxed, myAuxBin exhibits the default icon Why ? How can I solve this problem ? Thank you in advance.

Big Sur 11.2 I recently upgraded my Mac from Catalina to Big Sur. Since then Transporter.app fails to process the signed .pkg when I try to upload to the App Store: Could not create a temporary .itmsp package for the app “TakinSigned.pkg”. Failed to decompress the app. There is no log file, no explanation. The signed package is produced as for Catalina through the commands: productbuild --component "Takin.app" /Applications "Takin.pkg" productsign --sign <3rd Party Mac Developer Installer certificat> --keychain ~/Library/Keychains/login.keychain "Takin.pkg" “TakinSigned.pkg” Any suggestion ?

I have a bundle with a set of auxiliary binaries in folder Resources. I successfully signed and distributed it.When I try to publish it to the App Store Xcode complains (sandboxing is activated):------------------------------App sandbox not enabled. The following executables must include the “com.apple.security.app-sandbox” entitlement with a Boolean value of true in the entitlements property list:[( "eu.ill.fullprof4mac.pkg/Payload/FullProf4Mac.app/Contents/Resources/FullProf_Suite/Faults",“eu.ill.fullprof4mac.pkg/Payload/FullProf4Mac.app/Contents/Resources/FullProf_Suite/GLOpSAnn",“eu.ill.fullprof4mac.pkg/Payload/FullProf4Mac.app/Contents/Resources/FullProf_Suite/Mag_Info”,“eu.ill.fullprof4mac.pkg/Payload/FullProf4Mac.app/Contents/Resources/FullProf_Suite/Mag_SymmCal",….--------------------------------As far as I can see, Xcode's interface only handles the main binary (MacOS folder) but moving the auxiliary binaries to that folder would brake the package architecture (which is not designed by me).I manually added to the resource folder an entilement file for each of these binaries but I do not find how to warn Xcode of their presence. I checked the bundle with "RG App Checker Lite". It only detects the main entitlement file (the binary which is in folder MacOS) which confirms that something is wrong.All the best