[ad_1]
I’ve an extended historical past of writing about code signing in macOS. When Large Sur was launched, I assumed “Lastly!”
I used to be fallacious.
This time round I used to be tripped up by Safari, of all issues. It doesn’t open app archives like different components of macOS.
This story started with buyer studies of xScope being a “broken app” on Large Sur. This was shocking as a result of I had been downloading and testing the app on Large Sur for a number of months with out concern.
I used to be additionally doing all this work on Apple Silicon utilizing the DTK. And since Google Chrome wasn’t but engaged on this gadget, all my testing was restricted to Safari. Safari’s default setting is to open “secure” recordsdata after obtain, so I left that alone (as most prospects would).
That is the place I shot myself within the foot. At no level did my downloads contact the Archive Utility. And I had no concept that Safari’s code is totally different than the system utility.
Once I checked the signature of the app downloaded with Safari, all the things appears to be like good:
$ codesign -vvvv ~/Downloads/xScope.app ... /Customers/CHOCK/Downloads/xScope.app: legitimate on disk /Customers/CHOCK/Downloads/xScope.app: satisfies its Designated Requirement
Issues had been very totally different when utilizing Google Chrome:
$ codesign -vvvv ~/Downloads/xScope.app /Customers/CHOCK/Downloads/xScope.app: unsealed contents current within the root listing of an embedded framework In subcomponent: /Customers/CHOCK/Downloads/xScope.app/Contents/Frameworks/Sparkle.framework $ codesign -vvvv ~/Downloads/xScope.app/Contents/Frameworks/Sparkle.framework /Customers/CHOCK/Downloads/xScope.app/Contents/Frameworks/Sparkle.framework: a sealed useful resource is lacking or invalid file added: /Customers/CHOCK/Downloads/xScope.app/Contents/Frameworks/Sparkle.framework/Variations/Present/Assets/._fr_CA.lproj file added: /Customers/CHOCK/Downloads/xScope.app/Contents/Frameworks/Sparkle.framework/Variations/Present/Assets/Updater.app/Contents/Assets/._fr_CA.lproj file added: /Customers/CHOCK/Downloads/xScope.app/Contents/Frameworks/Sparkle.framework/Variations/Present/Assets/Updater.app/Contents/Assets/._pt.lproj file added: /Customers/CHOCK/Downloads/xScope.app/Contents/Frameworks/Sparkle.framework/Variations/Present/Assets/._pt.lproj
It seems all these people complaining a few “broken app” had been both utilizing Chrome or had Safari’s “secure” file dealing with turned off. The broken archive wasn’t getting repaired mechanically by Safari.
The root of the issue is localization within the Sparkle framework. There are two symlinks with prolonged attributes (the “._” is the place macOS shops issues like Finder info). The intent of the symlink was to say that French Canadian is identical as French, and Portuguese is identical as Brazilian Portuguese.
Since macOS mechanically makes this inference, it’s secure to simply delete the scripts that create the symlinks. In your Sparkle mission, discover any occurrences of “Run Script: Hyperlink fr_CA to fr” and “Run Script: Hyperlink pt to pt_BR” in your Goal Construct Phases and take away them. I had them in “Sparkle”, “SparkleCore”, and “Installer Progress”.
After you construct and notarize, you’ll see that your app is “legitimate on disk” regardless of the way it’s unarchived.
I’ve additionally submitted this info to Apple’s Product Safety group. As I mentioned in my e mail, the most important drawback right here is expectations:
The rationale I’m writing is as a result of Safari’s implementation for opening “secure” recordsdata is someway bypassing a code signing verify or repairing the downloaded package deal. The Archive Utility doesn’t. Buyer and developer expectations for unzipping archives is that they don’t seem to be modified and behave the identical manner throughout all Apple merchandise.
In the event you’re a Mac developer who’s utilizing Sparkle and distributing your product by way of an online obtain, now’s a very good time to verify how issues work in quite a lot of browsers. I’ve heard that we’re not the one ones affected.
And should you encounter a obtain that’s broken due to these Sparkle symlinks, this fast repair within the Terminal will set issues proper:
$ ditto xScope.app xScopeFixed.app $ rm -rf xScope.app $ mv xScopeFixed.app xScope.app
The ditto command strips the prolonged attributes which can be inflicting the difficulty. This may occasionally, in reality, be what Safari is doing for “secure” recordsdata.
All that’s left to do now could be marvel what surprises codesign has in retailer for subsequent yr’s launch of macOS…
[ad_2]
Source_link