macOS packaging: Perform ad-hoc signing of macOS bundle by default

[fwcd]

Starting with arm64 macOS Apple will require ad-hoc signatures, completely unsigned app bundles will no longer launch:

This branch fixes the issue by setting an ad-hoc signature, which only includes a checksum, by default if no other code signing identity is provided. With this patch, Mixxx launches normally again:

While arm64 macOS isn't officially supported by Mixxx yet, setting an ad-hoc signature on x86 too probably cannot hurt and fixing discrepancies between the x86 and arm64 builds in in advance is IMO always a good idea.

Marked as a draft PR for now since I haven't tested it with the x86 build yet.

[uklotzde]

Looks reasonable. Thank you for the detailed and helpful comments!

Could be merged after confirmed to work as expected.

[fwcd]

Hm, so there seems to be an issue with dynamic linking here, Mixxx crashes at startup and notes that one of the libraries didn't pass the validation check:

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace DYLD, Code 1 Library missing
Library not loaded: @executable_path/../Frameworks/libchromaprint.1.5.0.dylib
Referenced from: /Users/USER/Downloads/mixxx.app/Contents/MacOS/mixxx
Reason: tried: '/Users/USER/Downloads/mixxx.app/Contents/MacOS/../Frameworks/libchromaprint.1.5.0.dylib' (code signature in <0D1C9E79-A9D4-3E1B-8B54-6F67437E93C0> '/Users/USER/Downloads/mixxx.app/Contents/Frameworks/libchromaprint.1.5.0.dylib' not valid for use in process: mapped file has no Team ID and is not a platform binary (signed with custom identity or adhoc?)), '/usr/lib/libchromaprint.1.5.0.dylib' (no such file)
(terminated at launch; ignore backtrace)

The reason why I didn't encounter this issue on ARM was presumably that I linked the dependencies statically, circumventing the issue. I am not entirely sure why this happens with ad-hoc signatures, Team ID-based library validation doesn't make much sense there (at least I would think so). According to a thread on the Apple developer forums disabling library validation might be an option (since we're making an unsigned build this shouldn't be much of a security issue), perhaps the easiest way would be not passing entitlements at all if the signing identity is set to -. Thoughts?

[daschuer]

Maybe we have messed up something when building the environment. Can you check if this is also an issue with the main branch and using this patch?

[fwcd]

I am using the GitHub Actions build from this repo of this PR, so that shouldn't be the issue

[fwcd]

Not entirely sure why I was statically linking previously either, apparently the newer 2.4+ buildenvs produce static libraries and the older ones contain dylibs, but I haven't figured out why...

[daschuer]

We have moved form our Jenkins server with custom scripts and dynamic libraries to a vcpkg based solution which is using static builds by default.

[Be-ing]

Not entirely sure why I was statically linking previously either, apparently the newer 2.4+ buildenvs produce static libraries and the older ones contain dylibs, but I haven't figured out why...

vcpkg builds static libraries by default on macOS (and Linux) (microsoft/vcpkg#19127). The 2.3 dependencies were not built with vcpkg (https://github.com/mixxxdj/buildserver)

[daschuer]

@fwcd

Thoughts?

So it sounds like we have too options, disabling library validation for these private PR builds or merge this PR to main.
Is this correct? Both solution work for me.

I am not sure if the extra mile for a solution in the dynamic case will pay back. What do you think?

[fwcd]

I have solved the issue now by disabling the hardened runtime (which includes library validation) if and only if an ad-hoc code signing identity is used. This should now yield the correct result in all cases, regardless of whether dynamic or static linking is used.

Before merging, I would like to verify that it works with the ARM build, otherwise this should be ready for review!

[fwcd]

Seems to work well with the ARM build too.

cc @daschuer

[daschuer]

LGTM, thank you.