mirror of
https://github.com/l0ng-ai/tty7.git
synced 2026-09-21 16:02:20 +00:00
webdev
edfea5b830
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 <arch>, 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.