fix(release): strip x86_64 slice from Sparkle's Autoupdate before signing (fixes #309) - #312
Open
praxstack wants to merge 1 commit into
Open
fix(release): strip x86_64 slice from Sparkle's Autoupdate before signing (fixes #309)#312praxstack wants to merge 1 commit into
praxstack wants to merge 1 commit into
Conversation
…ning (fixes JerryZLiu#309) Sparkle ships Autoupdate as a universal (arm64+x86_64) binary in every release, including the latest (2.9.4). Dayflow itself is arm64-only, so this leftover Intel slice serves no purpose and triggers macOS's "Support Ending for Intel-based Apps" deprecation warning on Apple Silicon Macs — even though the app is fully native. Verified end-to-end against a real Release build (this machine has no Developer ID cert, so verification uses ad-hoc signing, but the mechanism is identical to the script's own codesign calls): 1. Built Release config, confirmed the bug reproduces: lipo -info Autoupdate -> "x86_64 arm64" 2. Applied the fix in the script's actual signing order (strip, then re-sign each Sparkle component, then the framework container, then the whole app last, matching release_dmg.sh's existing sequence). 3. codesign --verify --deep --strict --verbose=2 on the result: "valid on disk" / "satisfies its Designated Requirement" 4. Final lipo check: Autoupdate is arm64-only in the fully-signed app. The strip is gated on actually finding an x86_64 slice, so this is a no-op (and harmless) if a future Sparkle release ships arm64-only.
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.
fixes #309
what
adds a
lipo -thin arm64step for Sparkle'sAutoupdatebinary inscripts/release_dmg.sh, right before it gets re-signed.why
Sparkle ships
Autoupdateas a universal (arm64+x86_64) binary in every release, including the latest (2.9.4) — confirmed by downloading and checking it directly. Dayflow itself is arm64-only, so that leftover Intel slice serves no purpose and is what triggers the "Support Ending for Intel-based Apps" warning on Apple Silicon, even though the app is fully native.verification
this machine has no Developer ID cert, so I verified with ad-hoc signing — same
codesignmechanism the script already uses, just a different signing identity. built a real Release config, confirmed the bug, applied the fix in the exact order the script already signs things (strip → re-sign each Sparkle component → re-sign the framework container → sign the whole app last):the strip is gated on actually finding an x86_64 slice (
grep -q x86_64), so it's a safe no-op if a future Sparkle release ever ships arm64-only.Follow-up hardening pass (2026-07-08)
Ran an internal hardening pass (independent code review + verification) on this branch — no additional issues found; no changes made (PR head remains
baa5624).What was checked:
scripts/release_dmg.sh, +7/-0), no stray touches.lipo -infoguard matches a universal (x86_64 arm64) Autoupdate; in-placelipo -thin arm64produces a non-fat arm64 binary; the strip runs beforecodesignof Autoupdate, the framework container, and the whole app, so no signature seal is broken.xcodebuild ... build→BUILD SUCCEEDEDon this branch.Follow-up hardening pass (2026-07-08)
Re-verified the release-script change: shellcheck (0.11.0, -S warning) passes clean on the whole script; confirmed
lipo -thin arm64 <f> -output <f>(same input/output path) is byte-identical to extracting to a separate file (sha256 match on the real fat Autoupdate binary), so the in-place strip carries no corruption risk. End-to-end run against a real Release build still verifies: strip -> re-sign ->codesign --verify --deep --strictpasses, final binary is arm64-only. No code change needed.