macOS: Linker-signed libraries signed at install-time crash with hardened runtime
When using hardened runtime for an application, macOS will enforce termination of a process that tries to load libraries that failed library validation checks. Among those tests is a comparison between the file modification timestamp and its code-signing timestamp.
On modern macOS systems, maybe due to APFS, this leads to a situation where a library created with an ad-hoc code-signature (e.g., to be loaded/run from the build tree on Apple Silicon Macs), which is then install
-ed into its final destination (i.e., inside an app bundle), has its rpath
-entries fixed up, and gets finally code-signed with the actual developer ID, results in crashing the loading application because the second code-signing leads to a "tampered" library.
There is a radar filed for this behavior (https://openradar.appspot.com/FB8914243), but in informal talks with Apple this was confirmed as not a bug, but intended behavior: a code-signed library cannot be code-signed again at a later date and used in hardened runtime environments.
Apple suggested using ditto
to copy the library before fixing it up and code-signing it to ensure that macOS will treat it as a separate file.
As such it would be desirable if CMake itself could ensure that for file copy operations or install
targets actual clones are created to avoid this issue.
Noticeably, macOS will terminate the application on launch and even though the fixed library has been put into the application bundle, the crash log points to the same library in the build tree as the library that failed validation.