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 !

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