Bundle and re-sign libusb for the signed macOS CLI - #6
Merged
cboulay merged 1 commit intoJul 6, 2026
Merged
Conversation
Copy link
Copy Markdown
Contributor
Sorry, something went wrong.
The released MCCOutletCLI linked libusb by absolute Homebrew path. Once the CLI is Developer-ID signed with the hardened runtime it is subject to library validation and may only load dylibs signed by Apple or the same Team ID. Homebrew's libusb bottle is signed by a different team, so dyld refused it unconditionally and the shipped CLI was unrunnable on every machine (including ones with `brew install libusb`). CI missed this because the smoke test runs in the build job, before the sign-macos job adds the hardened runtime, on a runner that has brew libusb. Fix, in the sign-macos job before the CLI is signed: treat libusb exactly like lsl.framework. Copy the dylib into the CLI's Frameworks/ dir (preferring the macdeployqt'd app copy, falling back to the CLI's current reference so it works on both /opt/homebrew and /usr/local runners), normalize its install name to @rpath, repoint the CLI, and sign the dylib with the Developer ID before the CLI (dependency before dependent). The dylib ships automatically since Frameworks is already in the tarball. Also add a guardrail: after signing, fail the build if the CLI still links any absolute brew dylib. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The released MCCOutletCLI from the signed macOS tarball is dead on arrival on every machine — even ones with brew install libusb:
The GUI app is fine; only the CLI is broken.
Root cause
Two facts combine:
Why CI didn't catch it
The MCCOutletCLI --help smoke tests run in the build job, before the sign-macos job adds the hardened runtime, on a runner that has brew libusb. Unsigned/non-hardened binaries can load cross-team dylibs, so the pre-signing test passes, then signing silently breaks the shipped artifact.
Fix
In the sign-macos job, before sign_and_notarize.sh runs on the CLI, treat libusb exactly like lsl.framework:
The dylib ships automatically — Frameworks is already in the release tarball.
Verification
Manually validated the equivalent steps against the v3.2.0 asset on both a dev Mac and a deployed study computer: after the repoint + re-sign the CLI runs and enumerates an attached USB-1608FS-Plus. Once this ships, the downstream brnbci-deploy workaround that repoints + re-signs the binary post-download becomes a no-op.
🤖 Generated with Claude Code