From edfea5b830ac3747f44a22529715bd9289d0cd43 Mon Sep 17 00:00:00 2001 From: webdev <86946125+biztex@users.noreply.github.com> Date: Thu, 20 Aug 2026 08:30:42 +0700 Subject: [PATCH] ci(macos): assert every Mach-O in the bundle is the arch it ships as (#687) (#692) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A macOS 26 user opened the Apple Silicon build and was told it "contains Intel parts" (#687). Downloading what is actually published — v26.8.2, v26.8.3 and the nightly after #605 — and reading every file's Mach-O header says otherwise: the three binaries under Contents/MacOS are thin arm64, nothing else in the bundle is Mach-O at all, and tty7-app's load commands are all /System/Library/Frameworks and /usr/lib. The build is right today. The likeliest reading of the warning is macOS pinning an x86_64 program someone ran in a pane on tty7.app as the responsible process — the same attribution bundle-macos.sh already documents for TCC — and that belongs on the issue, not in this change. What does belong here is that nothing would have caught it if the report had been right. assert-macho.sh knows how to say "this is a 64-bit Mach-O for , it links only what macOS ships, and it is signed", and since #605 it has said it — about the standalone tty7-server asset, and only that. It has never been pointed at anything inside the .app. A helper built without --target on an Intel runner, a dylib dragged in from /opt/homebrew, a universal binary from a toolchain that decided to be helpful: each would have zipped, notarized and shipped, and the first check would have been a user's Finder. So check the bundle, in bundle-macos.sh, where release.yml and nightly.yml both build it. After the signing block — assert-macho.sh insists on a signature, and this way one pass covers Developer ID and adhoc alike — and before the update zip and the DMG, so a bundle that fails never becomes an artifact, and before the `mv` that dissolves dist/tty7.app. First the binaries the script staged itself: tty7-app, tty7 and, when it is packaged, tty7-updater, each through assert-macho.sh at the full standard the server asset is held to. That also leaves every shipped binary's load commands in the release log, which is where the next report of this kind gets answered from. Then a sweep of every file in the bundle: `file` says which are Mach-O of any kind, `lipo -archs` names the slices in each, and the answer has to be exactly the matrix arch. Any other name is the wrong build; two names is a universal binary, which is what the report described. lipo judges rather than a parse of `file`'s prose because Apple's `file` and upstream libmagic word the arch differently and lipo's slice names do not move. A sweep that finds fewer Mach-Os than the binaries staged above fails as well, so a changed wording cannot quietly turn it into a no-op. On a Developer ID build this runs after notarization, which spends a few minutes of notary time on a bundle that was never going to ship. Cheap next to carrying a second copy of the block inside each signing branch. Deliberately not a fix for what the reporter saw, if it is the child-process attribution: no check at build time can speak for a binary the user runs inside a pane. What it guarantees is narrower and worth having — the bundle named arm64 contains nothing but arm64, and a release where that stops being true fails on the runner. Validated with bash -n and shellcheck, and by running the sweep — and the whole script in its adhoc posture — on Linux against fake bundles with file, lipo, otool, codesign, ditto and hdiutil stubbed: a clean bundle passes and packages; a wrong-arch updater, a universal tty7-app, a stray x86_64 dylib, an arm64e nested bundle and an empty bundle each fail and name the file, and nothing is zipped after a failure. Not yet run on a Mac; the next nightly is what answers that. --- .github/scripts/bundle-macos.sh | 86 +++++++++++++++++++++++++++++++++ 1 file changed, 86 insertions(+) diff --git a/.github/scripts/bundle-macos.sh b/.github/scripts/bundle-macos.sh index 632a3c3a..f488a70c 100755 --- a/.github/scripts/bundle-macos.sh +++ b/.github/scripts/bundle-macos.sh @@ -9,6 +9,10 @@ # -> hardened-runtime signature, then notarize + staple. Passes Gatekeeper. # * Otherwise -> adhoc signature, same as before. Fine for local dev, but the # OS will quarantine it on other machines. +# +# Before either artifact is packaged, every Mach-O inside the bundle is +# asserted to be a thin binary (the sweep below), so a wrong-arch +# or universal file fails the build here instead of shipping. set -euo pipefail TARGET="$1" @@ -199,6 +203,88 @@ else codesign --force --deep --sign - "$APP" fi +# ---- Architecture sweep ---------------------------------------------------- +# Everything the bundle ships has to be the thin slice its filename claims. A +# macOS 26 user read "contains Intel parts" off the Apple Silicon bundle (#687). +# The published bundles turned out clean — every Mach-O in them thin arm64 — +# but nothing here had ever checked: assert-macho.sh only ever pointed at the +# standalone tty7-server asset, so a helper built without --target, a dylib +# dragged in from the runner, or a universal binary would have shipped, and been +# found by a user rather than by this script. +# +# After the signing block, because assert-macho.sh also insists on a code +# signature, and after both postures so one pass covers Developer ID and adhoc +# alike. Before the zip and the DMG, so a bundle that fails here never becomes +# an artifact — and before the `mv` below, after which dist/tty7.app no longer +# exists. For a Developer ID build that puts it after notarization, which +# spends a few minutes of notary time on a bundle that was never going to ship; +# cheap next to carrying a second copy of this block inside each branch. +BUNDLE_FAIL=0 +ASSERT_MACHO="$(dirname "$0")/assert-macho.sh" +BUNDLED_BINS=(tty7-app tty7) +if [[ "$PACKAGE_UPDATE_ZIP" != "0" ]]; then + BUNDLED_BINS+=(tty7-updater) +fi +# First the binaries we staged ourselves, held to the full standard the server +# asset is: the right arch, links nothing macOS does not ship, carries a +# signature. This also leaves every shipped binary's load commands in the +# release log, which is where the next report like #687 gets answered from. +for bin in "${BUNDLED_BINS[@]}"; do + bash "$ASSERT_MACHO" "$APP/Contents/MacOS/$bin" "$ARCH" || BUNDLE_FAIL=1 +done + +# Then the whole bundle, for whatever that list did not know to look at: walk +# every file, let `file` say which are Mach-O of any kind — executable, dylib, +# bundle — and have `lipo` name the slices in each. The answer has to be +# exactly "$ARCH". Any other name is the wrong build; two names is a universal +# binary, which is what the report described and what nothing in this pipeline +# should ever produce. +# +# `file` detects and `lipo -archs` judges, rather than reading the arch out of +# `file`'s prose: Apple's build says "64-bit executable arm64" where upstream +# libmagic says "64-bit arm64 executable, flags:<...>", and a parser written +# against one misreads the other. lipo's slice names are the same on every +# macOS, and it is the tool that would have made a fat binary in the first +# place. Captured into variables, never piped into `grep -q` — see +# assert-macho.sh for the pipefail race. Process substitution rather than +# `find | while`, so the counters survive the loop. +echo "--- Mach-O sweep of $APP, expecting ${ARCH} ---" +SWEEP_SEEN=0 +while IFS= read -r -d '' f; do + KIND="$(file -b "$f")" + [[ "$KIND" == *"Mach-O"* ]] || continue + SWEEP_SEEN=$((SWEEP_SEEN + 1)) + # Multi-line for a universal file (one line per slice); the first line is + # the verdict. + KIND="${KIND%%$'\n'*}" + if ! ARCHS="$(lipo -archs "$f" 2>&1)"; then + echo "::error::lipo could not read $f ($KIND): $ARCHS" + BUNDLE_FAIL=1 + continue + fi + case "$ARCHS" in + "$ARCH") + echo "${ARCHS} $f ($KIND)" ;; + *" "*) + echo "::error::$f is a universal binary carrying [${ARCHS}]; this bundle ships ${ARCH} only" + BUNDLE_FAIL=1 ;; + *) + echo "::error::$f is ${ARCHS}, not ${ARCH} ($KIND)" + BUNDLE_FAIL=1 ;; + esac +done < <(find "$APP" -type f -print0) +# A sweep that sees fewer Mach-Os than the binaries copied in above is not +# looking at the bundle — a changed `file` wording, an empty find — and must not +# pass as "nothing wrong found". +if (( SWEEP_SEEN < ${#BUNDLED_BINS[@]} )); then + echo "::error::the sweep found ${SWEEP_SEEN} Mach-O file(s) in $APP, fewer than the ${#BUNDLED_BINS[@]} staged above — it is not seeing the bundle" + BUNDLE_FAIL=1 +fi +if [[ "$BUNDLE_FAIL" -ne 0 ]]; then + exit 1 +fi +echo "✅ every Mach-O in $APP is a thin ${ARCH} binary (${SWEEP_SEEN} checked)" + # The in-app updater needs the signed, notarized .app itself rather than a disk # image that requires Finder interaction. The helper re-reads the full embedded # version out of the staged bundle and refuses anything that is not the release