[dotnet] Runtime pack retains Homebrew Brotli paths and breaks hardened-runtime app redistribution

[ttrias]

Summary

The Apple-silicon dotnet 10.0.302 bottle modifies the .NET macOS runtime pack's libSystem.IO.Compression.Native.dylib so that it depends on Homebrew's external Brotli libraries. When that runtime-pack binary is copied into a self-contained, Developer ID-signed macOS application, hardened runtime rejects the external Brotli library because it has a different signing Team ID. The application can be signed and notarized successfully but aborts in dyld before launch.

Bottle evidence

This can be inspected without installing the formula:

brew update
brew fetch --formula dotnet
bottle="$(brew --cache --formula dotnet)"
work="$(mktemp -d)"
tar -xzf "$bottle" -C "$work"
runtime_lib="$(find "$work" -path '*Microsoft.NETCore.App.Runtime.osx-arm64*' -name libSystem.IO.Compression.Native.dylib -print -quit)"
otool -L "$runtime_lib"

For the current ARM64 Tahoe bottle (dotnet 10.0.302, bottle SHA-256 a420ba0e0a6f87c5b62327a4f40c6d2130bf589af985ec6ed02f7c00d9067cec), the output includes:

@@HOMEBREW_PREFIX@@/opt/dotnet/libexec/shared/Microsoft.NETCore.App/10.0.10/libSystem.IO.Compression.Native.dylib
/usr/lib/libz.1.dylib
@@HOMEBREW_PREFIX@@/opt/brotli/lib/libbrotlidec.1.dylib
@@HOMEBREW_PREFIX@@/opt/brotli/lib/libbrotlienc.1.dylib
/usr/lib/libSystem.B.dylib

After installation, the placeholders resolve under /opt/homebrew. A net10.0-macos Release build with osx-arm64, hardened runtime, and Developer ID signing copies this native library into MyApp.app/Contents/MonoBundle. The application then fails at launch with:

Termination Reason: Namespace DYLD, Code 1, Library missing
Library not loaded: /opt/homebrew/opt/brotli/lib/libbrotlidec.1.dylib
Referenced from: MyApp.app/Contents/MonoBundle/libSystem.IO.Compression.Native.dylib
Reason: mapping process and mapped file (non-platform) have different Team IDs

The app bundle and installer passed strict codesign verification, Apple notarization, stapling, and Gatekeeper assessment. Those checks did not catch the external runtime dependency.

Comparison with Microsoft's SDK

The corresponding native library installed by Microsoft's official .NET 10.0.302 SDK does not depend on Homebrew or external Brotli libraries:

@rpath/libSystem.IO.Compression.Native.dylib
/usr/lib/libSystem.B.dylib

Rebuilding the same application with Microsoft's SDK produced a signed bundle with no non-system absolute dependencies and the application launched successfully.

Expected behavior

Native libraries under Microsoft.NETCore.App.Runtime.osx-arm64 should remain suitable for self-contained macOS publication. Ideally, the formula would preserve the upstream relocatable runtime-pack binaries instead of relinking them to Homebrew dependencies. If that is not compatible with Homebrew policy, the formula should clearly warn that it cannot safely produce hardened-runtime redistributable macOS applications.

If Homebrew retains those external links, preserving .NET's --self-contained contract requires the Homebrew-provided SDK to package the external native dependency closure into the application. Bundling those libraries is not an optional workaround; it is the alternative implementation of a genuinely self-contained runtime. That closure must include not only libbrotlidec and libbrotlienc, but also dependencies such as libbrotlicommon, inside the application bundle—for example, under Contents/Frameworks.

The publish integration would also need to:

• rewrite Homebrew absolute load commands to relocatable @loader_path or @rpath references;
• recursively reject any dependency that remains under /opt/homebrew, /usr/local, or another build-machine-specific path;
• preserve the target architecture and include the applicable third-party license notices;
• perform all copying and Mach-O load-command changes before code signing;
• allow the nested libraries to be signed with the same application identity when hardened runtime library validation is enabled; and
• validate the final packaged payload by launching it without Homebrew or DYLD_LIBRARY_PATH available.

A runtime pack that leaves Brotli under /opt/homebrew is framework- or environment-dependent in practice, even when the project was published with --self-contained. Merely requiring Brotli to be installed on the target machine would not preserve self-contained runtime semantics and would continue to fail on clean Macs. If Homebrew cannot provide or maintain this publishing integration, preserving the upstream runtime-pack binaries is the simpler and safer behavior.

Environment

Homebrew 6.0.15
dotnet formula 10.0.302
Microsoft.NETCore.App runtime 10.0.10
macOS 26.6 arm64
Xcode 26.6
Apple silicon; Rosetta not installed

I could not use the Homebrew Core issue template because brew doctor reports intentional local conditions, including centrally owned Homebrew directories and FileMaker ODBC libraries under /usr/local/lib. The template directs reports with unresolved doctor warnings to Discussions.

Disclosure: I used OpenAI Codex to help inspect the binaries and draft this report. I verified the commands and output and will answer maintainer questions myself.

[SMillerDev]

This sounds like a bug in dotnet to me. It copies libraries without checking their dependencies and doesn't resign any libraries either?

[ttrias]

Thanks. .NET publish copies the runtime-pack asset and does not recursively discover arbitrary Mach-O dependencies introduced into that asset; signing is normally a later application-packaging step. In our pipeline, every Mach-O file inside the app bundle was recursively signed, and the finished app passed codesign --verify --deep --strict. The problem was that Homebrew's libbrotlidec/libbrotlienc were not copied into the bundle at all: the copied compression dylib still referred to them by absolute /opt/homebrew paths, so those external files retained Homebrew's signature and different Team ID.

We have now verified a narrow workaround against the same application:

1. Detect the two Brotli load commands in Contents/MonoBundle/libSystem.IO.Compression.Native.dylib.
2. Copy libbrotlidec, libbrotlienc, and their transitive libbrotlicommon dependency into Contents/Frameworks.
3. Rewrite the load commands and dylib IDs to bundle-relative @loader_path/@rpath references.
4. Preserve the app's effective entitlements (including com.apple.security.cs.allow-jit) and sign the copied/modified libraries and enclosing app with the same Developer ID identity.
5. Include Brotli's license notice.

After that, all 14 Mach-O files in the bundle had only system or bundle-relative dependencies, all nested libraries had the app's Team ID, strict signature verification passed, and both the app and the app extracted from a newly signed installer launched successfully. Brotli was the only external dependency family found in that scan.

So I agree that .NET's publisher could be made more defensive about recursively closing native dependencies. The Homebrew-specific concern is that Microsoft's official 10.0.302 runtime-pack asset has no external Brotli dependency, while the Homebrew-built asset does. That changes an upstream self-contained runtime-pack binary into one that depends on the build machine's Homebrew prefix. The application publisher can compensate with logic like the above, but preserving the upstream relocatable asset would avoid requiring every .NET macOS packager to implement that Homebrew-specific closure and re-signing step.

[SMillerDev]

I that's still something to raise with the dotnet developers. Homebrew compiles dotnet using their provided install instructions.
If dotnet can't handle the dependencies that its install script uses, that seems like a bug to me.

[ttrias]

Thanks—we've now raised this upstream with the .NET team:

https://github.com/dotnet/runtime/issues/131885

The report frames this as a source-built runtime-pack / --self-contained native dependency-closure issue. It includes the Homebrew bottle evidence, the hardened-runtime failure, the comparison with Microsoft's official SDK, and the verified Brotli-vendoring workaround. It also asks the runtime, source-build, or SDK maintainers to redirect it internally if another layer owns the fix.

We'll follow the upstream issue and report back here if the resolution requires a Homebrew-side change.