Issues with codesigning and notarization for Mac M1

Question

I'm working to correctly distribute a software bundle for Mac ARMS (M1, M2...) which consists in a zip containing a bunch of command line utilities and dynamic libraries built using the command line tools (cc, c++ etc).

So far I've been able to sign all my executable files and my dynamic libraries with codesign using my company Developer ID certificate and to successfully notarize the zip.

Unfortunately when I download the zip using the browser my command line tools show a strange behavior: if I double click on of them from finder I get an error message saying that the identity of the developer can't be confirmed but if I run from the terminal most of the utilities work. I've noticed that if I download the last jdk as .tar.gz the behavior with the java executable is the same so I'm wondering if it's the expected behavior for command line utilities.

Still one of the utilities is not working because it is supposed to load the dynamic libraries I get an error saying that relative paths are not allowed in hardened programs.

My questions are: Is the behavior described above for command line executable files expected? Is there a way to allow my program that loads dynamic library to work by loading dynamic libraries as it used to do with our unsigned bundles for Intel Macs? Does anyone knows if it's possible to notarize and distribute such a bundle in .tar.gz format rather than zip?

Thanks!

Answer 1

Thanks to the suggestions of Richard Barber I've finally understood how to correctly code-sing, notarize and deploy our bundles on Mac with hardened runtimes. I'm leaving the steps I've taken below for future reference.

Here are the steps I needed to run:

• Made sure all the dynamic executable files and libraries have referenced their dependencies without using relative paths. The relative paths may be substituted with macros like @rpath using install_name_tool
• Code-singed all executable files and all the dynamic libraries suing the codesign tool with a valid Apple Distribution certificate and developer/organization key
• Once signed put everything in a ZIP and sent for notarization using xcrun notarytool submit command
• If the notarization succeeds the contents of the ZIP can be extracted and put in a .tar.gz without losing the validity

Once the tar.gz is downloaded on a testing machine our command line tools can be correctly used by the terminal. As suggested by Richard Barber they can't be run from Finder, but even the JDK in tar.gz format shows the same behavior, so happy with that.

Answer 2

For macOS notarized software that means the executable is going to have the hard-coded path to the library and won’t work with a relative path. Usually that means setting RPATH to the hardpath

/Applications/myapp.app/Contents/Frameworks/

and aliasing your binaries from

/Applications/myapp.app/Contents/MacOS

But that is just the most common arrangement.
The hard-coded path is part of the “hardened runtime” which is a requirement to pass apple notary, an anti-malware scanner. Changing the assigned RPATH with otool is possible but invalidates the code signature, blocking execution on machines with default security without code signing at least ad hoc.

See

https://wiki.lazarus.freepascal.org/Code_Signing_for_macOS

Launching the executable directly from terminal does not run thru launchservices the way it does when you launch in finder. Launchservices begins by checking the signature against the ticket and checking the ticket, so a bare executable will be missing that info.