macosapple-m1code-signingnotarize

Issues with codesigning and notarization for Mac M1


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!


Solution

  • 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:

    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.