Fragile signatures that break with install_name_tool

[CendioOssman]

brew doctor output

Your system is ready to brew.

Verification

• My "brew doctor output" above says Your system is ready to brew. and am still able to reproduce my issue.
• I ran brew update twice and am still able to reproduce my issue.
• This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

brew config output

HOMEBREW_VERSION: 4.4.17
ORIGIN: https://github.com/Homebrew/brew
HEAD: 55f399c10dc7e6cc07497bdfccdecc96329e3b57
Last commit: 5 days ago
Branch: stable
Core tap JSON: 24 Jan 11:47 UTC
Core cask tap JSON: 24 Jan 11:47 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 3.3.7 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.3.7/bin/ruby
CPU: octa-core 64-bit arm_firestorm_icestorm
Clang: 16.0.0 build 1600
Git: 2.39.5 => /Library/Developer/CommandLineTools/usr/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 15.2-arm64
CLT: 16.2.0.0.1.1733547573
Xcode: 16.2
Rosetta 2: false

What were you trying to do (and why)?

Construct a shippable bundle using macdeployqt, which in turn uses install_name_tool. Without this tool, my application would not run on users systems, as the required libraries from homebrew would not be included.

What happened (include all command output)?

My application crashes on load with SIGKILL.

What did you expect to happen?

My application starts normally.

Step-by-step reproduction instructions (by running brew commands)

This would require a complete Qt project, so difficult to give a short example. I'll add some more commands to show the issue as comments.

[CendioOssman]

The problem is that macOS on ARM requires everything to be "signed". It is perfectly happy with what Apple calls "adhoc" signatures, though.

Homebrew properly provides those since #9102. But the details make them fragile and break easily.

To make your application independent of Homebrew, you usually include the required libraries in the app bundle. This requires modifying the libraries so that they find their dependencies in the bundle, and not in the standard homebrew path. Apple includes the tool install_name_tool for this.

The problem is that changing the path of those dependencies changes the contents of the files, and hence breaks the signatures, which in turn makes the system refuse to load them.

In most other cases, this works fine for two reasons:

• Apple's linker implicitly does adhoc signatures
• install_name_tool redoes the signatures when it sees that it is one of those implicit signatures

This does not work with homebrew libraries because homebrew adds it own signatures, rather than getting them from the linker.

install_name_tool even warns about this when it sees that it is messing up a signature:

/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: QtCore

[CendioOssman]

I think the ideal fix is that homebrew also has those implicit signatures.

I don't know why you aren't getting them already from the linker, so I don't know how difficult it would be to fix things to get them the "normal" way.

There is an easy alternative, though. You can add the flag -o linker-signed to codesign and it will add a signature the same way the linker does.

[MikeMcQuaid]

I'll let others chime in but: note that Homebrew does not provide libraries for distribution but for our own use. A used to be a professional Qt developer and Homebrew maintainer at the same time and when I was: I used the official Qt libraries for distribution for this reason (among others).

[CendioOssman]

Most open source projects don't have official binaries to use. So even if we would go that more complicated path, it wouldn't really be feasible.

It would most likely mean we need to build everything ourselves if we want to provide a complete app bundle to our users. :/

[MikeMcQuaid]

Most open source projects don't have official binaries to use.

You referenced macdeployqt, that's why we're talking about Qt here.

It would most likely mean we need to build everything ourselves if we want to provide a complete app bundle to our users. :/

Yes, you probably should be doing this. Even if the install_name_tool issues didn't bite you: macOS SDK ones likely would/will because bottles are built only for the targeted macOS version (and hardware) and newer. If you need to work on any OSs older than Homebrew works: you're out of luck.