I have a long history of writing about code signing in macOS. When Big Sur was released, I thought “Finally!”
I was wrong.
This time around I was tripped up by Safari, of all things. It doesn’t open app archives like other parts of macOS.
This story began with customer reports of xScope being a “damaged app” on Big Sur. This was surprising because I had been downloading and testing the app on Big Sur for several months without issue.
I was also doing all this work on Apple Silicon using the DTK. And since Google Chrome wasn’t yet working on this device, all my testing was limited to Safari. Safari’s default setting is to open “safe” files after download, so I left that alone (as most customers would).
This is where I shot myself in the foot. At no point did my downloads touch the Archive Utility. And I had no idea that Safari’s code is different than the system utility.
When I checked the signature of the app downloaded with Safari, everything looks good:
$ codesign -vvvv ~/Downloads/xScope.app ... /Users/CHOCK/Downloads/xScope.app: valid on disk /Users/CHOCK/Downloads/xScope.app: satisfies its Designated Requirement
Things were very different when using Google Chrome:
$ codesign -vvvv ~/Downloads/xScope.app /Users/CHOCK/Downloads/xScope.app: unsealed contents present in the root directory of an embedded framework In subcomponent: /Users/CHOCK/Downloads/xScope.app/Contents/Frameworks/Sparkle.framework $ codesign -vvvv ~/Downloads/xScope.app/Contents/Frameworks/Sparkle.framework /Users/CHOCK/Downloads/xScope.app/Contents/Frameworks/Sparkle.framework: a sealed resource is missing or invalid file added: /Users/CHOCK/Downloads/xScope.app/Contents/Frameworks/Sparkle.framework/Versions/Current/Resources/._fr_CA.lproj file added: /Users/CHOCK/Downloads/xScope.app/Contents/Frameworks/Sparkle.framework/Versions/Current/Resources/Updater.app/Contents/Resources/._fr_CA.lproj file added: /Users/CHOCK/Downloads/xScope.app/Contents/Frameworks/Sparkle.framework/Versions/Current/Resources/Updater.app/Contents/Resources/._pt.lproj file added: /Users/CHOCK/Downloads/xScope.app/Contents/Frameworks/Sparkle.framework/Versions/Current/Resources/._pt.lproj
It turns out all these folks complaining about a “damaged app” were either using Chrome or had Safari’s “safe” file handling turned off. The damaged archive wasn’t getting repaired automatically by Safari.
The root of the problem is localization in the Sparkle framework. There are two symlinks with extended attributes (the “._” is where macOS stores things like Finder information). The intent of the symlink was to say that French Canadian is the same as French, and Portuguese is the same as Brazilian Portuguese.
Since macOS automatically makes this inference, it’s safe to just delete the scripts that create the symlinks. In your Sparkle project, find any occurrences of “Run Script: Link fr_CA to fr” and “Run Script: Link pt to pt_BR” in your Target Build Phases and remove them. I had them in “Sparkle”, “SparkleCore”, and “Installer Progress”.
After you build and notarize, you’ll see that your app is “valid on disk” no matter how it’s unarchived.
I’ve also submitted this information to Apple’s Product Security group. As I said in my email, the biggest problem here is expectations:
The reason I’m writing is because Safari’s implementation for opening “safe” files is somehow bypassing a code signing check or repairing the downloaded package. The Archive Utility does not. Customer and developer expectations for unzipping archives is that they are not modified and behave the same way across all Apple products.
If you’re a Mac developer who’s using Sparkle and distributing your product via a web download, now’s a good time to check how things work in a variety of browsers. I’ve heard that we’re not the only ones affected.
And if you encounter a download that’s damaged because of these Sparkle symlinks, this quick fix in the Terminal will set things right:
$ ditto xScope.app xScopeFixed.app $ rm -rf xScope.app $ mv xScopeFixed.app xScope.app
The ditto command strips the extended attributes that are causing the issue. This may, in fact, be what Safari is doing for “safe” files.
All that’s left to do now is wonder what surprises codesign has in store for next year’s release of macOS…