Apple ARM binary codesign issue

Ryan Schmidt ryandesign at
Thu Sep 24 03:58:53 UTC 2020

On Sep 22, 2020, at 17:24, Ken Cunningham wrote:

> On 2020-09-22, at 12:58 PM, Ryan Schmidt wrote:
>> To me it seems unrealistic for Apple to suggest that an infinite number of open source projects, many of whose developers have never seen a Mac, should now add code to their build systems to codesign things on macOS. Apple made a point of stating during WWDC that they love open source software; imposing busy work on the open source community is not a good way to show that love.
> As I read it, the linker automatically codesigns the binary when you link, which is usually the final step in the process. So nobody has to change anything there.
> But if you later modify that final linked binary by stripping it (I guess ) or changing the libraries around with install_name_tool (which I believe MESON does to every single install :>)  then you invalidate the signature, as you should IMHO.

The operative word is "you". In this case, "you" could be the project's build system, or it could be the portfile fixing things up after the build system got something wrong. My paragraph refers to the former: to projects that invoke install_name_tool or strip as part of their build process, and my contention that asking those projects to add codesigning steps to those is unreasonable. As for the latter, I don't recall any ports calling strip manually, but there are many that use install_name_tool; ideally, those should be fixed so that they don't need to do that (i.e. by fixing the build system to use the -install_name flag correctly when linking).

Apple only just introduced the requirement that everything be codesigned in a very recent macOS 11 beta, and only just introduced the change into a recent Xcode 12 beta that causes the linker to automatically sign things. It would not surprise me if Apple introduces further changes in later betas that automatically re-sign things when using install_name_tool or strip.

More information about the macports-dev mailing list