Fix Wireshark Sparkle updates selecting Intel builds on Apple Silicon#563
Open
moreaki wants to merge 1 commit into
Open
Fix Wireshark Sparkle updates selecting Intel builds on Apple Silicon#563moreaki wants to merge 1 commit into
moreaki wants to merge 1 commit into
Conversation
|
I haven't read through all the code, but wouldn't it make sense to use the architecture of the actual app for all apps, not just for Wireshark/Stratoshark, in case other apps behave the same way? |
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
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.
Summary
This fixes Wireshark/Stratoshark Sparkle updates resolving the wrong architecture-specific feed on Apple Silicon, which could lead to an ARM install being updated to the Intel build.
Closes #454.
Root cause
Latest currently reads
SUFeedURLdirectly from the target app bundle and treats it as authoritative.For Wireshark and Stratoshark, the bundled macOS plist ships a static
SUFeedURLthat points to thex86-64appcast path. Their own updater code then rewrites that URL at runtime based on the actual build architecture (x86-64vsarm64).That means external Sparkle consumers like Latest can end up using the Intel feed for an Apple Silicon install even though the installed bundle itself is ARM.
There was also a secondary precision issue in our Sparkle path: we resolved bundles by bundle identifier during check/install instead of preferring the exact on-disk bundle URL selected by the user.
Changes
Bundle(url:)overBundle(identifier:)when creating Sparkle updaters for both checking and installingVerification
xcodebuild build -project 'Latest.xcodeproj' -scheme 'Latest' -destination 'platform=macOS' CODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY=''I also added a focused XCTest for the feed rewrite logic. I could not execute the test target successfully in this local environment because
Latest Testsfailed to resolve the private framework module dependenciesCommerceKitandStoreFoundation, but the app build itself succeeds.Upstream
I opened an upstream Wireshark issue about the bundled Sparkle metadata always shipping an
x86-64SUFeedURL: